Re: [PATCH] KVM: x86: Update Xen-specific CPUID leaves during mangling

[Sean Christopherson <seanjc@google.com>]

On Wed, Jan 22, 2025, David Woodhouse wrote:
> On Wed, 2025-01-22 at 18:44 +0100, Vitaly Kuznetsov wrote:
> > > What is the purpose of the comparison anyway?

To avoid scenarios where KVM has configured state for a set of features X, and
doesn't correctly handle vCPU features suddenly become Y.  Or more commonly,
where correctly handling such transitions (if there's even a "correct" option)
is a complete waste of time and complexity because no sane setup will ever add
and/or remove features from a running VM.

> > > IIUC we want to ensure that a VMM does not change its mind after KVM_RUN
> > > so should we not be stashing what was set by the VMM and comparing
> > > against that *before* mangling any values?
> > 
> > I guess it can be done this way but we will need to keep these 'original'
> > unmangled values for the lifetime of the vCPU with very little gain (IMO):
> > KVM_SET_CPUID{,2} either fails (if the data is different) or does (almost)
> > nothing when the data is the same.

More importantly, userspace is allowed to set the CPUID returned by KVM_GET_CPUID2.
E.g. selftests do KVM_GET_CPUID2 specifically to read the bits that are managed
by KVM.

Disallowing that would likely break userspace, and would create a weird ABI where
the output of KVM_GET_CPUID2 is rejected by KVM_SET_CPUID2.

> If they're supposed to be entirely unchanged, would it suffice just to
> keep a hash of them?