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:20:25 +0100 Message-ID: <52827F79.70909__46823.8503592604$1384283968$gmane$org@redhat.com> References: <20131112183321.GN13369@zion.uk.xensource.com> <52827C0B.5040901@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <52827C0B.5040901@redhat.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 20:05, Laszlo Ersek wrote: > 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? Even if it doesn't (because Xen uses a different way to pass the information): perhaps a common function that turns an e820 table into a bunch of HOBs would be useful. The pointer to the first entry could be derived differently, dependent on the specific accelerator, but the translation could be common. (Of course I'm only assuming that qemu's etc/e820 fw_cfg file would be appropriate for these HOBs. I could be wrong.) Thanks Laszlo