Re: [SeaBIOS] [PATCH] SeaBIOS/Xen: Compute the low RAM memory size in the BDA according to the e820
On Mon, Nov 14, 2011 at 02:03:38AM +0000, Julian Pidancet wrote:
On Mon, Nov 14, 2011 at 1:11 AM, Kevin O'Connor kevin@koconnor.net wrote:
That wont work reliably - SeaBIOS (and option roms) can grow the EBDA. It's not realistic to put a whole in the middle of the first 640k.
When you say "grow" do you mean grow downwards ? Because if not, the ACPI info structure lives in 9F000, so there shouldn't be any problem reporting the 0-9F000 range as the memory size in the BDA.
Yes - the EBDA grows down. Both SeaBIOS itself can grow the EBDA (see pmm.c:zonelow_expand) and option roms can grow the EBDA.
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?
The AML interpreter should be able to see all of ram, so that doesn't seem like an issue.
-Kevin
On Mon, Nov 14, 2011 at 2:09 AM, Kevin O'Connor kevin@koconnor.net 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 Pidancet -
Kevin O'Connor