Hi all Currently OVMF determines memory size by consulting CMOS, then it makes up memory map of its own. Consulting memory size by reading CMOS limits the RAM size to 1TB as there''s only 3 bytes from 0x5b-0x5d in CMOS, where the upper memory size is stored. And from Xen''s point of view, OVMF should use the memory mapped passed by hypervisor (from hvmloader) instead of making up its own. To solve the above two problems all in one go, I plan to pass necessary information (io resource, mmio resource) to OVMF from Xen. I will construct the table / structure in hvmloader then hook up platform pei code when OVMF is running on Xen. The first thing that comes in mind is to reuse E820 table for memory map plus some extra fields for io / mmio resources. But I guess UEFI is the new world so stuffs like E820 from old world will be less popular. Any suggestion on existing table / data structure I can use? Thanks Wei.
Konrad Rzeszutek Wilk
2013-Nov-12 19:22 UTC
Re: Passing Xen memory map and resource map to OVMF
On Tue, Nov 12, 2013 at 06:33:21PM +0000, Wei Liu wrote:> Hi all > > Currently OVMF determines memory size by consulting CMOS, then it makes > up memory map of its own. > > Consulting memory size by reading CMOS limits the RAM size to 1TB as > there''s only 3 bytes from 0x5b-0x5d in CMOS, where the upper memory size > is stored. > > And from Xen''s point of view, OVMF should use the memory mapped passed > by hypervisor (from hvmloader) instead of making up its own. > > To solve the above two problems all in one go, I plan to pass necessary > information (io resource, mmio resource) to OVMF from Xen. I will > construct the table / structure in hvmloader then hook up platform pei > code when OVMF is running on Xen./me nods. The nice thing about that is that it could also allow us to modify the E820 from the toolstack for any combination we want. For example if you use e820_host=1 in your PV guest the E820 will look like the host one. Great for PCI passthrough when you have some stubborn cards.> > The first thing that comes in mind is to reuse E820 table for memory map > plus some extra fields for io / mmio resources. But I guess UEFI is the > new world so stuffs like E820 from old world will be less popular. Any > suggestion on existing table / data structure I can use?I think the E820 is fine. After all the Linux kernel picks up the EFI memmap and then stuffs it in E820. And there are some patches that do this for HVM already: http://article.gmane.org/gmane.comp.emulators.xen.devel/170593 for which I was hoping could be reworked as needed.> > > Thanks > Wei. > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel
On Tue, Nov 12, 2013 at 10:33 AM, Wei Liu <wei.liu2@citrix.com> wrote:> Hi all > > Currently OVMF determines memory size by consulting CMOS, then it makes > up memory map of its own. > > Consulting memory size by reading CMOS limits the RAM size to 1TB as > there''s only 3 bytes from 0x5b-0x5d in CMOS, where the upper memory size > is stored. > > And from Xen''s point of view, OVMF should use the memory mapped passed > by hypervisor (from hvmloader) instead of making up its own. > > To solve the above two problems all in one go, I plan to pass necessary > information (io resource, mmio resource) to OVMF from Xen. I will > construct the table / structure in hvmloader then hook up platform pei > code when OVMF is running on Xen. > > The first thing that comes in mind is to reuse E820 table for memory map > plus some extra fields for io / mmio resources. But I guess UEFI is the > new world so stuffs like E820 from old world will be less popular. Any > suggestion on existing table / data structure I can use?Is OvmfPkg/Include/Guid/XenInfo.h helpful on the OVMF side? Regarding E820 structures, I guess I''d suggest copying the E820 structures from IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBiosInterface.h into a new OvmfPkg/Include/IndustryStandard/E820.h file. -Jordan
On Tue, 2013-11-12 at 14:22 -0500, Konrad Rzeszutek Wilk wrote:> On Tue, Nov 12, 2013 at 06:33:21PM +0000, Wei Liu wrote: > > Hi all > > > > Currently OVMF determines memory size by consulting CMOS, then it makes > > up memory map of its own. > > > > Consulting memory size by reading CMOS limits the RAM size to 1TB as > > there''s only 3 bytes from 0x5b-0x5d in CMOS, where the upper memory size > > is stored. > > > > And from Xen''s point of view, OVMF should use the memory mapped passed > > by hypervisor (from hvmloader) instead of making up its own. > > > > To solve the above two problems all in one go, I plan to pass necessary > > information (io resource, mmio resource) to OVMF from Xen. I will > > construct the table / structure in hvmloader then hook up platform pei > > code when OVMF is running on Xen. > > /me nods. The nice thing about that is that it could also allow us > to modify the E820 from the toolstack for any combination we want.Note that the right way to do that would be for the toolstack to communicate the base e820 to hvmloader, which would then do what it needs to do modifying as it went and plumb the result through to the BIOS. Ian.
On Tue, 2013-11-12 at 18:33 +0000, Wei Liu wrote:> Hi all > > Currently OVMF determines memory size by consulting CMOS, then it makes > up memory map of its own. > > Consulting memory size by reading CMOS limits the RAM size to 1TB as > there''s only 3 bytes from 0x5b-0x5d in CMOS, where the upper memory size > is stored. > > And from Xen''s point of view, OVMF should use the memory mapped passed > by hypervisor (from hvmloader) instead of making up its own. > > To solve the above two problems all in one go, I plan to pass necessary > information (io resource, mmio resource) to OVMF from Xen. I will > construct the table / structure in hvmloader then hook up platform pei > code when OVMF is running on Xen.FWIW when hvmloader launches SeaBIOS it passes this stuff in a struct at a known location: struct xen_seabios_info { char signature[14]; /* XenHVMSeaBIOS\0 */ u8 length; /* Length of this struct */ u8 checksum; /* Set such that the sum over bytes 0..length == 0 */ /* * Physical address of an array of tables_nr elements. * * Each element is a 32 bit value contianing the physical address * of a BIOS table. */ u32 tables; u32 tables_nr; /* * Physical address of the e820 table, contains e820_nr entries. */ u32 e820; u32 e820_nr; } PACKED; The e820 is not self identifiable so it gets its own field. The "tables" are the ACPI RSDP, the mptables, the smbios tables and the PIR tables. SeaBIOS iterates over these and identifies them by their unique signature, ignoring any which it doesn''t understand for forwards compatibility. I don''t know which if any of those tables are suitable to be passed into OVMF, I guess some of them are legacy BIOS things... But the general shape of the scheme is probably worth following... Ian.
On Tue, Nov 12, 2013 at 11:51:10AM -0800, Jordan Justen wrote:> On Tue, Nov 12, 2013 at 10:33 AM, Wei Liu <wei.liu2@citrix.com> wrote: > > Hi all > > > > Currently OVMF determines memory size by consulting CMOS, then it makes > > up memory map of its own. > > > > Consulting memory size by reading CMOS limits the RAM size to 1TB as > > there''s only 3 bytes from 0x5b-0x5d in CMOS, where the upper memory size > > is stored. > > > > And from Xen''s point of view, OVMF should use the memory mapped passed > > by hypervisor (from hvmloader) instead of making up its own. > > > > To solve the above two problems all in one go, I plan to pass necessary > > information (io resource, mmio resource) to OVMF from Xen. I will > > construct the table / structure in hvmloader then hook up platform pei > > code when OVMF is running on Xen. > > > > The first thing that comes in mind is to reuse E820 table for memory map > > plus some extra fields for io / mmio resources. But I guess UEFI is the > > new world so stuffs like E820 from old world will be less popular. Any > > suggestion on existing table / data structure I can use? > > Is OvmfPkg/Include/Guid/XenInfo.h helpful on the OVMF side? >It needs to be extended to hold more information.> Regarding E820 structures, I guess I''d suggest copying the E820 > structures from > IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBiosInterface.h into a > new OvmfPkg/Include/IndustryStandard/E820.h file. >Thanks for the pointer. Wei.> -Jordan