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>'. 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
