On Fri, Sep 02, 2022 at 10:44:20AM +0200, Gerd Hoffmann wrote: > Hi, > > > I feel there are three major sources of controversy here > > > > 0. the cover letter and subject don't do such a good job > > explaining that what we are doing is just telling guest > > CPUID is not broken. we are not exposing anything new > > and not exposing host capability to guest, for example, > > if cpuid phys address is smaller than host things also > > work fine. > > > > 1. really the naming. We need to be more explicit that it's just a bugfix. > > Yep, I'll go improve that for v2. > > > 2. down the road we will want to switch the default when no PV. however, > > some hosts might still want conservative firmware for compatibility > > reasons, so I think we need a way to tell firmware > > "ignore phys address width in CPUID like you did in the past". > > let's add a flag for that? > > and if none are set firmware should print a warning, though I > > do not know how many people will see that. Maybe some ;) > > > /* > > * Force firmware to be very conservative in its use of physical > > * addresses, ignoring phys address width in CPUID. > > * Helpful for migration between hosts with different capabilities. > > */ > > #define KVM_BUG_PHYS_ADDRESS_WIDTH_BROKEN 2 > > I don't see a need for that. Live migration compatibility can be > handled just fine today using > 'host-phys-bits=on,host-phys-bits-limit=<xx>' > > Which is simliar to 'phys-bits=<xx>'. yes but what if user did not configure anything? the point of the above is so we can eventually, in X years, change the guests to trust CPUID by default. > The important difference is that phys-bits allows pretty much anything > whereas host-phys-bits-limit applies sanity checks against the host > supported phys bits and throws error on invalid values. > > take care, > Gerd
