On 14/11/2011 03:36, "Kevin O'Connor" <kevin@xxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|