On Mon, Nov 14, 2011 at 2:09 AM, Kevin O'Connor <kevin@xxxxxxxxxxxx> wrote:
>
> Yes - the EBDA grows down. Both SeaBIOS itself can grow the EBDA (see
> pmm.c:zonelow_expand) and option roms can grow the EBDA.
>
I ignored that. Thanks for the info.
>> > As above, this doesn't look right - SeaBIOS will still locate the EBDA
>> > at 9fc00 and nothing will stop it from growing it over the 9f000 area.
>> >
>>
>> The EBDA is a standard bios structure, can't we safely assume that
>> it's size will hardly change ? If not, would you suggest that this
>> ACPI info structure should be placed at a different location ? The
>> problem with this is that it has to be in a location with a fixed
>> address, and preferably in a location which is accessible by any AML
>> interpreter.
>
> 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.
> 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 ?
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.
--
Julian
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|