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