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.
> Regardless, since we must uphold this misbehavior as ABI, we have a
> regression since KVM doesn't override the MSR write if it comes after
> the CPUID write.
>
> > I agree that KVM should keep its nose out of this stuff, especially since most
> > VMX controls are technically not architecturally tied to CPUID. But we probably
> > need an opt-in from userspace to stop mucking with the MSRs.
>
> Bleh, I wanted to avoid the age-old problem of naming, but alas...
I think a single quirk would suffice, e.g. KVM_X86_QUIRK_KVM_DOESNT_LIKE_TO_SHARE.
