Re: ovmf / PCI passthrough impaired due to very limiting PCI64 aperture

["Dr. David Alan Gilbert" <dgilbert@redhat.com>]

* Gerd Hoffmann (kraxel@redhat.com) wrote:
>   Hi,
> 
> > (a) We could rely in the guest physbits to calculate the PCI64 aperture.
> 
> I'd love to do that.  Move the 64-bit I/O window as high as possible and
> use -- say -- 25% of the physical address space for it.
> 
> Problem is we can't.
> 
> > failure. Also, if the users are not setting the physbits in the guest,
> > there must be a default (seems to be 40bit according to my experiments),
> > seems to be a good idea to rely on that.
> 
> Yes, 40 is the default, and it is used *even if the host supports less
> than that*.  Typical values I've seen for intel hardware are 36 and 39.
> 39 is used even by recent hardware (not the xeons, but check out a
> laptop or a nuc).
> 
> > If guest physbits is 40, why to have OVMF limiting it to 36, right?
> 
> Things will explode in case OVMF uses more physbits than the host
> supports (host physbits limit applies to ept too).  In other words: OVMF
> can't trust the guest physbits, so it is conservative to be on the safe
> side.
> 
> If we can somehow make a *trustable* physbits value available to the
> guest, then yes, we can go that route.  But the guest physbits we have
> today unfortunately don't cut it.

In downstream RH qemu, we run with host-physbits as default; so it's reasonably
trustworthy; of course that doesn't help you across a migration between
hosts with different sizes (e.g. an E5 Xeon to an E3).
Changing upstream to do the same would seem sensible to me, but it's not
a foolproof config.

Dave

> take care,
>   Gerd
> 
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK