On 11/12/13 19:33, 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.
>
> 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?
As far as I understand / remember, we're not really dynamic wrt. memory
layout in PEI, even on pure qemu or with KVM. I think it would be useful
to key off some memory map provided by the emulator (although I'm sure
we'd run into regressions in some spots, but those can be fixed later).
As far as I can see, qemu exports an fw_cfg table called "etc/e820". See
qemu commit
commit 7d67110f2d9a6a2d6b5215a948abc95d07258735
Author: Gerd Hoffmann <kra...@redhat.com>
Date: Fri Oct 18 11:31:54 2013 +0200
pc: add etc/e820 fw_cfg file
Unlike the existing FW_CFG_E820_TABLE entry which carries reservations
only the new etc/e820 file also has entries for RAM.
Format is simliar to the FW_CFG_E820_TABLE, it is a simple list of
e820_entry structs. Unlike FW_CFG_E820_TABLE it has no count though
as the number of entries can be figured from the file size.
Cc: Andrea Arcangeli <aarca...@redhat.com>
Signed-off-by: Gerd Hoffmann <kra...@redhat.com>
Does this work when qemu is used in combination with Xen?
Maybe we could use a common interface here that would work independently
of the qemu accelerator.
"OvmfPkg/Library/QemuFwCfgLib" is a BASE library, so I *think* we should
be free to use it in "OvmfPkg/PlatformPei" (which is a PEIM).
OVMF already contains a structure definition for the E820 entry (called
"struct e820_entry"), since commit
Author: Jordan Justen <jordan.l.jus...@intel.com>
Date: Fri Nov 2 18:26:30 2012 +0000
OvmfPkg: Add Linux bzimage include file
This file is from the efilinux project where it resides
under the path loaders/bzimage/bzimage.h.
git://git.kernel.org/pub/scm/boot/efilinux/efilinux.git
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.jus...@intel.com>
Reviewed-by: Laszlo Ersek <ler...@redhat.com>
Acked-by: Matt Fleming <matt.flem...@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@13920
6f19259b-4bc3-4df7-8a09-765794883524
I guess this defintion could be moved to a more "neutral" location (from
"Include/IndustryStandard/LinuxBzimage.h" to
"Include/IndustryStandard/E820.h" or some such), and then you could
reuse it in the new code.
I also recall that an e820-related fw_cfg file has been introduced
recently to qemu, it has to do with the 64-bit PCI hole?... Igor? :)
Thanks,
Laszlo
------------------------------------------------------------------------------
DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
Free app hosting. Or install the open source package on any LAMP server.
Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
