Re: [PATCH 1/3] KVM: SVM: Check EFER.SVME before updating MSR_VM_CR on guest writes

[Jim Mattson]

On Thu, Oct 29, 2026 at 3:04 PM Jim Mattson <jmattson@xxxxxxxxxx> wrote:
>
> On Thu, Oct 29, 2026 at 2:52 PM Sean Christopherson <seanjc@xxxxxxxxxx> wrote:
> >
> > On Thu, Oct 29, 2026, Jim Mattson wrote:
> > > On Thu, Oct 29, 2026 at 2:19 PM Sean Christopherson <seanjc@xxxxxxxxxx> wrote:
> > > >
> > > > On Thu, Oct 29, 2026, Jim Mattson wrote:
> > > > > (Host- initiated writes are allowed to set any valid MSR_VM_CR bits.)
> > > >
> > > > Eww.  Why?  If we allow this, then we'll end up with the mess where the guest
> > > > can't write back the current value (if userspace is being weird).  I get that
> > > > we want to avoid ordering issues, but there's *already* a required order here,
> > > > unless userspace ignores the failure from svm_set_vm_cr() and continues on.
> > > >
> > > > KVM doesn't advertise the MSR as something to be saved/restored, and none of
> > > > QEMU, CHV, CrosVM, or our VMM appear to save/restore it.  So why make trouble
> > > > for ourselves?
> > >
> > > OMG! I didn't look any farther than the obviously broken svm_set_vm_cr().
> > >
> > > It looks like svm->nested.vm_cr_msr controls nothing other than itself.
> >
> > LOL, nice.
> >
> > > It's just 5 bits of storage with some weird locking rules, and it
> > > resets to 0 on suspend/resume.
> > >
> > > What is the point of such half-baked support?
> >
> > More than likely, so that older kernels didn't crash when writing an MSR KVM
> > didn't emulate. :-(
>
> You're not going to let me get rid of it, are you?

LOL! Even the 'LOCK' check is wrong:

 if (svm->nested.vm_cr_msr & SVM_VM_CR_SVM_DIS_MASK)
        chg_mask &= ~(SVM_VM_CR_SVM_LOCK_MASK | SVM_VM_CR_SVM_DIS_MASK);

The condition should be checking SVM_VM_CR_SVM_LOCK_MASK.

Well, at least it can be used as a sentinel you can poll to see if
your VM has live-migrated. :)