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?
