All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wei Liu <wei.liu2@citrix.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: Wei Liu <wei.liu2@citrix.com>,
	"Jordan Justen (Intel address)" <jordan.l.justen@intel.com>,
	edk2-devel@lists.sourceforge.net, xen-devel@lists.xen.org,
	Igor Mammedov <imammedo@redhat.com>,
	Laszlo Ersek <lersek@redhat.com>
Subject: Re: [edk2] Passing Xen memory map and resource map to OVMF
Date: Wed, 13 Nov 2013 16:56:44 +0000	[thread overview]
Message-ID: <20131113165644.GA16969__44426.0877593935$1384361920$gmane$org@zion.uk.xensource.com> (raw)
In-Reply-To: <1384352585.3560.36.camel@nilsson.home.kraxel.org>

On Wed, Nov 13, 2013 at 03:23:05PM +0100, Gerd Hoffmann wrote:
>   Hi,
> 
> > > > MMIO holes, IO range created by hvmloader.
> > > 
> > > Why?  All (memory) address space not backed by ram effectively is mmio.
> > > There is no need to explicitly declare holes ...
> > > 
> > 
> > Yes there is, because hvmloader is in charge of declaring holes.
> 
> Why does it declare holes in the first place?
> Just for ACPI _CRS?  Or other reasons too?
> 

The reason is hvmloader knows the constraints of where MMIO holes can be
put, so it arranges the holes itself to avoid tripping over Xen
limitation. If OVMF creates its own map it's going to cause problem.

One example is, when the guest has <2GB RAM, OVMF will allocate PCI
resources starting from 2GB. But hvmloader has already set host bridge
window to start at 4GB. When Linux boots up it finds existing BAR
incompatible with bridge window so it decides to relocate BAR to start
from 4GB. One of the many BARs is framebuffer, Xen cannot handle the
situation that framebuffer is moved from one location to another.

> > OVMF
> > should just use whatever it gets.
> 
> What would OVMF use them for?
> 

To reserve range for MMIO holes, so that later PCI resource allocation
protocol can only use those ranges.

Wei.

> As far I know hvmloader creates the acpi tables and initializes pci
> device mappings, so there isn't much to manage for ovmf ...
> 
> > > Also why io ranges?  Isn't pc io address space pretty much fixed anyway?
> > > 
> > 
> > This is not actually necessary, but I want to pass this anyway, just to
> > be consistent.
> 
> I don't see the point in passing it ...
> 
> cheers,
>   Gerd
> 

  parent reply	other threads:[~2013-11-13 16:56 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 ` [edk2] Passing Xen memory map and resource map to OVMF Laszlo Ersek
     [not found] ` <52827C0B.5040901@redhat.com>
2013-11-12 19:20   ` 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 [this message]
     [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='20131113165644.GA16969__44426.0877593935$1384361920$gmane$org@zion.uk.xensource.com' \
    --to=wei.liu2@citrix.com \
    --cc=edk2-devel@lists.sourceforge.net \
    --cc=imammedo@redhat.com \
    --cc=jordan.l.justen@intel.com \
    --cc=kraxel@redhat.com \
    --cc=lersek@redhat.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.