[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ovmf / PCI passthrough impaired due to very limiting PCI64 aperture
From: |
Eduardo Habkost |
Subject: |
Re: ovmf / PCI passthrough impaired due to very limiting PCI64 aperture |
Date: |
Wed, 17 Jun 2020 12:25:38 -0400 |
On Wed, Jun 17, 2020 at 10:17:55AM +0200, Christophe de Dinechin wrote:
>
>
> > Le 16 Jun 2020 à 19:10, Eduardo Habkost <ehabkost@redhat.com> a écrit :
> >
> > On Tue, Jun 16, 2020 at 05:57:46PM +0100, Dr. David Alan Gilbert wrote:
> >> * 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.
> >
> > Yeah, to make it really trustworthy we would need to prevent
> > migration to hosts with mismatching phys sizes.
>
> Wouldn't it be sufficient to prevent guestphysbits > hostphysbits?
It probably would, for the OVMF issue we're discussing here.
But it's not a guarantee we give today.
If we make additional guarantees to guest software, we need to
communicate them unambiguously to the guest.
--
Eduardo
- ovmf / PCI passthrough impaired due to very limiting PCI64 aperture, Guilherme G. Piccoli, 2020/06/16
- Re: ovmf / PCI passthrough impaired due to very limiting PCI64 aperture, Guilherme Piccoli, 2020/06/16
- Re: ovmf / PCI passthrough impaired due to very limiting PCI64 aperture, Gerd Hoffmann, 2020/06/17
- Re: ovmf / PCI passthrough impaired due to very limiting PCI64 aperture, Laszlo Ersek, 2020/06/17
- Re: ovmf / PCI passthrough impaired due to very limiting PCI64 aperture, Laszlo Ersek, 2020/06/17
- Re: ovmf / PCI passthrough impaired due to very limiting PCI64 aperture, Laszlo Ersek, 2020/06/17
- Re: ovmf / PCI passthrough impaired due to very limiting PCI64 aperture, Guilherme Piccoli, 2020/06/17
- Re: ovmf / PCI passthrough impaired due to very limiting PCI64 aperture, Laszlo Ersek, 2020/06/17