Re: [Xen-devel] [edk2] Passing Xen memory map and resource map to OVMF

[Wei Liu <wei.liu2@xxxxxxxxxx>]

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
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel