> Le 16 Jun 2020 à 19:10, Eduardo Habkost <ehabk...@redhat.com> a écrit : > > On Tue, Jun 16, 2020 at 05:57:46PM +0100, Dr. David Alan Gilbert wrote: >> * Gerd Hoffmann (kra...@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? > We would need to > communicate that to the guest somehow (with new hypervisor CPUID > flags, maybe). > > -- > Eduardo
