Re: [Qemu-devel] [PATCH 4/5] x86: Allow physical address bits to be set

[Igor Mammedov]

On Fri, 17 Jun 2016 11:17:54 +0200
Gerd Hoffmann <address@hidden> wrote:

> On Fr, 2016-06-17 at 10:43 +0200, Paolo Bonzini wrote:
> > 
> > On 17/06/2016 10:15, Dr. David Alan Gilbert wrote:  
> > > Larger is a problem if the guest tries to map something to a high
> > > address that's not addressable.  
> > 
> > Right.  It's not a problem for most emulated PCI devices (it would be a
> > problem for those that have large RAM BARs, but even our emulated video
> > cards do not have 64-bit RAM BARs, I think;  
> 
> qxl can be configured to have one, try "-device
> qxl-vga,vram64_size_mb=1024"
> 
> > >    2) While we have maxmem settings to tell us the top of VM RAM, do
> > >       we have anything that tells us the top of IO space? What happens
> > >       when we hotplug a PCI card?  
> 
> > (arch/x86/kernel/setup.c) but I agree that (2) is a blocker.  
> 
> seabios maps stuff right above ram (possibly with a hole due to
> alignment requirements).
> 
> ovmf maps stuff into a 32G-aligned 32G hole.  Which lands at 32G and
> therefore is addressable with 36 bits, unless you have tons of ram (>
> 30G) assigned to your guest.  A physical host machine where you can plug
> in enough ram for such a configuration likely has more than 36 physical
> address lines too ...
> 
> qemu checks where the firmware mapped 64bit bars, then adds those ranges
> to the root bus pci resources in the acpi tables (see /proc/iomem).
> 
> > You don't know how the guest will assign PCI BAR addresses, and as you
> > said there's hotplug too.  
> 
> Not sure whenever qemu adds some extra space for hotplug to the 64bit
> hole and if so how it calculates the size then.  But the guest os should
> stick to those ranges when configuring hotplugged devices.
currently firmware would assign 64-bit BARs after reserved-memory-end
(not sure about ovmf though) but QEMU on ACPI side will add 64-bit _CRS only
for firmware mapped devices (i.e. no space reserved for hotplug).
And is I recall correctly ovmf won't map BARs if it doesn't have
a driver for it so ACPI tables won't even have a space for not mapped
64-bit BARs.

There was another attempt to reserve more space in _CRS
  https://lists.nongnu.org/archive/html/qemu-devel/2016-05/msg00090.html


> 
> cheers,
>   Gerd
> 
>