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:48:28AM +0000, Julian Pidancet wrote:
On Mon, Nov 14, 2011 at 2:09 AM, Kevin O'Connor kevin@koconnor.net 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
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.
You can even create an "OEM" ACPI table, with std ACPI header, but with custom data inside. OS will ignore it and as bonus you will have it with checksum.
Thanks Rudolf
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
On 14/11/2011 08:53, "Keir Fraser" keir.xen@gmail.com wrote:
On 14/11/2011 03:36, "Kevin O'Connor" kevin@koconnor.net wrote:
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.
Like the attached patch (untested), which is a bit larger than anticipated, but actually allows code to be net deleted. :-)
-- Keir
-- Keir
-Kevin
Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Mon, Nov 14, 2011 at 1:23 PM, Keir Fraser keir@xen.org wrote:
On 14/11/2011 08:53, "Keir Fraser" keir.xen@gmail.com wrote:
On 14/11/2011 03:36, "Kevin O'Connor" kevin@koconnor.net wrote:
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.
Like the attached patch (untested), which is a bit larger than anticipated, but actually allows code to be net deleted. :-)
That was quick. I will give it a try shortly.
On Mon, Nov 14, 2011 at 01:23:41PM +0000, Keir Fraser wrote:
On 14/11/2011 08:53, "Keir Fraser" keir.xen@gmail.com wrote:
On 14/11/2011 03:36, "Kevin O'Connor" kevin@koconnor.net wrote:
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
Oops - that should have read 0xfec00000.
(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()
Since Xen lays out the PCI space (and assuming it wont put a PCI device at that address) that should be fine.
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.
Like the attached patch (untested), which is a bit larger than anticipated, but actually allows code to be net deleted. :-)
-Kevin
On Mon, Nov 14, 2011 at 1:23 PM, Keir Fraser keir@xen.org wrote:
On 14/11/2011 08:53, "Keir Fraser" keir.xen@gmail.com wrote:
On 14/11/2011 03:36, "Kevin O'Connor" kevin@koconnor.net wrote:
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.
Like the attached patch (untested), which is a bit larger than anticipated, but actually allows code to be net deleted. :-)
I just tested your patch with Windows 7 and Linux guest booted from iPXE.
Everything seems to work fine. SeaBIOS reports the following e820:
(XEN) HVM23: e820 map has 6 items: (XEN) HVM23: 0: 0000000000000000 - 000000000009f400 = 1 RAM (XEN) HVM23: 1: 000000000009f400 - 00000000000a0000 = 2 RESERVED (XEN) HVM23: 2: 00000000000f0000 - 0000000000100000 = 2 RESERVED (XEN) HVM23: 3: 0000000000100000 - 000000003f7ff000 = 1 RAM (XEN) HVM23: 4: 000000003f7ff000 - 000000003f800000 = 2 RESERVED (XEN) HVM23: 5: 00000000fc000000 - 0000000100000000 = 2 RESERVED
The ACPI code in Linux reports the right PCI memory window:
[ 0.338966] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug [ 0.340000] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff]) [ 0.341029] pci_root PNP0A03:00: host bridge window [io 0x0000-0x0cf7] [ 0.341965] pci_root PNP0A03:00: host bridge window [io 0x0d00-0xffff] [ 0.342965] pci_root PNP0A03:00: host bridge window [mem 0x000a0000-0x000bffff] [ 0.343965] pci_root PNP0A03:00: host bridge window [mem 0xf0000000-0xfbffffff]
Can you ship it ?
-
Julian Pidancet -
Keir Fraser -
Keir Fraser -
Kevin O'Connor -
Rudolf Marek