On Thu, Sep 22, 2022 at 7:16 AM Gerd Hoffmann <kraxel@xxxxxxxxxx> wrote: > > On Thu, Sep 22, 2022 at 02:38:02PM +0200, Paolo Bonzini wrote: > > On Thu, Sep 22, 2022 at 2:21 PM Gerd Hoffmann <kraxel@xxxxxxxxxx> wrote: > > > No. This will basically inform the guest that host-phys-bits has been > > > enabled (and pass the number of bits). So the firmware can make use of > > > the available address space instead of trying to be as conservative as > > > possible to avoid going beyond the (unknown) limit. > > > > Intel processors that are not extremely old have host-phys-bits equal > > to 39, 46 or 52. Older processors that had 36, in all likelihood, > > didn't have IOMMUs (so no big 64-bit BARs). > > Well, I happen to have a intel box with 36 physbits + iommu. > > > 1) set host-phys-bits to true on new machine types when not using TCG > > (i.e. KVM / HVF / WHPX) > > That is probably a good idea, but an independent problem. > > Has live migration problems (when hosts have different phys bits), > which is IIRC the reason this hasn't happen yet. Maybe that is solved > meanwhile the one way or another, I've seen some phys-bits changes in > libvirt recently ... > > > 2) in the firmware treat 40 as if it were 39, to support old machine > > types? > > The background of all this is that devices need more and more memory, > and the very conservative edk2 defaults are becoming increasingly > problematic. So what I want do is scale things up with the address > space size. Use 1/4 or 1/8 of the physical address space as 64bit > pci mmio window. Likewise scale up the default pcie root port window > sizes, to have more room for hotplug. > > For that to work the firmware obviously needs to know how much it > actually has, which is not the case. > > Yes, the problematic cases are intel machines with 36 or 39. > > Treating 40 as if it were 39 will explode with 36 cpus. > > Treating 40 as if it were 36 will mostly work. Will leave a big > chunk of address space unused. Will cause regressions on guests > with > 32G of RAM. > > Treating 40 as invalid and continue to use the current conservative > heuristic, otherwise treat phys-bits as valid might work. Obvious > corner case is that it'll not catch broken manual configurations > (host-phys-bits=off,phys-bits=<larger-than-host>), only the broken > default. Not sure how much of a problem that is in practice, maybe > it isn't. > > I think I still prefer to explicitly communicate a reliable phys-bits > value to the guest somehow. On x86 hardware, KVM is incapable of emulating a guest physical width that differs from the host physical width. There isn't support in the hardware for it.
