All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laszlo Ersek <lersek@redhat.com>
To: Wei Liu <wei.liu2@citrix.com>
Cc: "Jordan Justen (Intel address)" <jordan.l.justen@intel.com>,
	Igor Mammedov <imammedo@redhat.com>,
	edk2-devel@lists.sourceforge.net,
	Gerd Hoffmann <kraxel@redhat.com>,
	xen-devel@lists.xen.org
Subject: Re: [edk2] Passing Xen memory map and resource map to OVMF
Date: Tue, 12 Nov 2013 20:05:47 +0100	[thread overview]
Message-ID: <52827C0B.5040901__15259.0677761056$1384283110$gmane$org@redhat.com> (raw)
In-Reply-To: <20131112183321.GN13369@zion.uk.xensource.com>

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 <kraxel@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 <aarcange@redhat.com>
    Signed-off-by: Gerd Hoffmann <kraxel@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.justen@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.justen@intel.com>
    Reviewed-by: Laszlo Ersek <lersek@redhat.com>
    Acked-by: Matt Fleming <matt.fleming@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

       reply	other threads:[~2013-11-12 19:05 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20131112183321.GN13369@zion.uk.xensource.com>
2013-11-12 19:05 ` Laszlo Ersek [this message]
     [not found] ` <52827C0B.5040901@redhat.com>
2013-11-12 19:20   ` [edk2] Passing Xen memory map and resource map to OVMF Laszlo Ersek
2013-11-13  7:03   ` Gerd Hoffmann
     [not found]   ` <1384326219.3560.9.camel@nilsson.home.kraxel.org>
2013-11-13 11:58     ` Wei Liu
     [not found]     ` <20131113115811.GC4948@zion.uk.xensource.com>
2013-11-13 13:53       ` Gerd Hoffmann
     [not found]       ` <1384350814.3560.24.camel@nilsson.home.kraxel.org>
2013-11-13 14:06         ` Wei Liu
     [not found]         ` <20131113140654.GF4948@zion.uk.xensource.com>
2013-11-13 14:23           ` Gerd Hoffmann
     [not found]           ` <1384352585.3560.36.camel@nilsson.home.kraxel.org>
2013-11-13 16:56             ` Wei Liu
     [not found]             ` <20131113165644.GA16969@zion.uk.xensource.com>
2013-11-14  7:58               ` Gerd Hoffmann
     [not found]               ` <1384415898.15534.15.camel@nilsson.home.kraxel.org>
2013-11-14 10:47                 ` Wei Liu
2013-11-14 11:06                 ` Laszlo Ersek
     [not found]                 ` <20131114104738.GB23151@zion.uk.xensource.com>
2013-11-14 11:19                   ` Gerd Hoffmann
     [not found]                 ` <5284AEA4.6090004@redhat.com>
2013-11-14 16:42                   ` Andrew Fish
     [not found]                   ` <746A3CCD-E629-4AD5-9889-3BC89A7814F9@apple.com>
2013-11-15  7:18                     ` Gerd Hoffmann
2013-11-15 14:26                     ` Wei Liu
2013-11-13 16:51         ` Konrad Rzeszutek Wilk
2013-11-13 16:47     ` Konrad Rzeszutek Wilk
2013-11-12 19:22 ` Konrad Rzeszutek Wilk
2013-11-13 10:34   ` Ian Campbell
2013-11-12 19:51 ` Jordan Justen
2013-11-13 10:38 ` Ian Campbell
     [not found] ` <CAFe8ug92_AUd45s3MNA19nz-etSK-aZxKTqdsskFqDX9BBdTjA@mail.gmail.com>
2013-11-13 11:59   ` Wei Liu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='52827C0B.5040901__15259.0677761056$1384283110$gmane$org@redhat.com' \
    --to=lersek@redhat.com \
    --cc=edk2-devel@lists.sourceforge.net \
    --cc=imammedo@redhat.com \
    --cc=jordan.l.justen@intel.com \
    --cc=kraxel@redhat.com \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.