On Wed, Feb 2, 2022 at 4:55 PM Sean Christopherson <seanjc@xxxxxxxxxx> wrote:
>
> On Wed, Feb 02, 2022, Oliver Upton wrote:
> > On Wed, Feb 2, 2022 at 4:33 PM Sean Christopherson <seanjc@xxxxxxxxxx> wrote:
> > > MSR_IA32_FEAT_CTL has this same issue. But that mess also highlights an issue
> > > with this series: if userspace relies on KVM to do the updates, it will break the
> > > existing ABI, e.g. I'm pretty sure older versions of QEMU rely on KVM to adjust
> > > the MSRs.
> >
> > I realize I failed to add a note about exactly this in the cover
> > letter. It seems, based on the commit 5f76f6f5ff96 ("KVM: nVMX: Do not
> > expose MPX VMX controls when guest MPX disabled") we opted to handle
> > the VMX capability MSR in-kernel rather than expecting userspace to
> > pick a sane value that matches the set CPUID. So what really has
> > become ABI here? It seems as though one could broadly state that KVM
> > owns VMX VM-{Entry,Exit} control MSRs without opt-in, or narrowly
> > assert that only the bits in this series are in fact ABI.
>
> I don't know Paolo's position, but personally I feel quite strongly that KVM should
> not manipulate the guest vCPU model. KVM should reject changes that put the kernel
> at risk, but otherwise userspace should have full control.
I agree wholeheartedly. Userspace should not have to do KVM_GET_CPUID2
after KVM_SET_CPUID2 to find out what the guest's actual CPUID table
looks like. However, today, it does.
Similarly, for read-only MSRs, userspace should be able to assume that
KVM_GET_MSRS will always return the same value that was passed to
KVM_SET_MSRS. However, that is not the case today, either.
