On 14/11/2011 03:36, "Kevin O'Connor" kevin@koconnor.net wrote:
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.
I suggest we stick it at FC000000, and shift hvmloader's mem_alloc() starting address up by one page to FC001000. The acpi build code will have to manually mem_hole_populate_ram() that one page before writing to it. This can then be documented in hvmloader/config.h which contains a description of, and defines for, the system memory map. This is by far the easiest solution to this problem; manually crafting an SSDT is a right pain in the arse, whereas this is maybe a 5-line patch.
-- Keir
-Kevin
Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel