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. take care, Gerd
