From mboxrd@z Thu Jan 1 00:00:00 1970 From: Laszlo Ersek Subject: Re: [edk2] Passing Xen memory map and resource map to OVMF Date: Tue, 12 Nov 2013 20:05:47 +0100 Message-ID: <52827C0B.5040901__15259.0677761056$1384283110$gmane$org@redhat.com> References: <20131112183321.GN13369@zion.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20131112183321.GN13369@zion.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Wei Liu Cc: "Jordan Justen (Intel address)" , Igor Mammedov , edk2-devel@lists.sourceforge.net, Gerd Hoffmann , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org 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 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 Signed-off-by: Gerd Hoffmann 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 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 Reviewed-by: Laszlo Ersek Acked-by: Matt Fleming 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