Re: Why do we need the ACPI machine language?
Posted: Fri Mar 31, 2017 3:45 pm
Korona I may have to disagree with your statements....
Memtest86 / Linux can already get RAM SPD information. I would guess it's not difficult to expand SPD information to include a "Persistent Memory" flag.
If IBM PC/AT compatibility isn't required then legacy chips can be removed and everything is enumerated via PCI bus. ACPI/AML is total overkill.
Wrong statement as shown by answers below.And much less reliable and forward compatible.
The PCI Host Bridge device has the 'MCFG' table in it's Configuration Space. Much more simpler and reliable than the bloated disaster known as ACPI.How do you enumerate PCI root complexes? We already have NUMA systems with multiple PCI roots.
VT-d could be represented by a standard PCI device. Any attempt to map the VT-d PCI device to a virtual machine would throw an errorPlus there are devices that fundamentally cannot be part of the PCI, for example VT-d and persistent memory DIMMs.
Memtest86 / Linux can already get RAM SPD information. I would guess it's not difficult to expand SPD information to include a "Persistent Memory" flag.
I/O APIC is not a "legacy" device, you go that wrong.It would also mean that we would never be able to get rid of stuff like ATA or the other legacy chips like the PIT, PIC, I/O APIC and RTC.
If IBM PC/AT compatibility isn't required then legacy chips can be removed and everything is enumerated via PCI bus. ACPI/AML is total overkill.
The mechanism is the PCI Configuration space.You need some mechansim to enumerate and relocate devices on the system bus.