On Mon, Nov 14, 2011 at 02:48:28AM +0000, Julian Pidancet wrote:
On Mon, Nov 14, 2011 at 2:09 AM, Kevin O'Connor kevin@koconnor.net wrote:
Why does it have to be at a fixed location? What structure is actually placed at this address?
Xen's hvmloader automatically computes the size of the PCI memory and stores the PCI memory range adresses in that structure. It also provide information about wether some devices are present (uart, hpet, ect...). The ACPI code that we inject in the guest has the address of this structure hardcoded, and it contains some tricks to make the AML interpreter go read the values contained in it, and take action to expose the right information to the guest OS. Like the right PCI root window for example.
I'm not at all an ACPI expert, I don't know if there's a better way to expose to the guest the right information.
Unfortunately, there aren't very many places to put a hardcoded address. The safest thing is probably to dynamically generate an SSDT with a pointer - then the DSDT can use the pointer instead of a hardcoded address. This is more work, however.
The AML interpreter should be able to see all of ram, so that doesn't seem like an issue.
Like I said, I'm not an ACPI expert. But let say we decide to move this ACPI info structure to some other area, where there's less risk for it to be overwritten, like somewhere above 0xFC000000, wouldn't that prevent some Operating System with limited memory capabilities to access it ?
If the OS can handle AML it can handle 32bit addresses.
Besides, it seems that SeaBIOS manages itself the space between 0xFC000000 and 4G, so it seems difficult to imagine to have a reserved space with a fixed address in there.
On Xen, the PCI init code isn't used, so assuming this struct doesn't need to live in real "ram", I think it could live just about anywhere past the end of ram. Even with pciinit.c, addresses over 0xfc00000 (with the exception of a few bytes for hpet, apic, ioapic, and bios image) could be used.
-Kevin