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@xxxxxxxxxxxx> 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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home