Re: [PATCH] KVM: x86: Disallow setting CPUID and/or feature MSRs if L2 is active

[Sean Christopherson]

On Wed, Jan 07, 2026, Yosry Ahmed wrote:
> On Wed, Jan 07, 2026 at 08:47:02PM +0000, Yosry Ahmed wrote:
> > On Tue, Dec 30, 2025 at 12:56:41PM -0800, Sean Christopherson wrote:
> > > Extend KVM's restriction on CPUID and feature MSR changes to disallow
> > > updates while L2 is active in addition to rejecting updates after the vCPU
> > > has run at least once.  Like post-run vCPU model updates, attempting to
> > > react to model changes while L2 is active is practically infeasible, e.g.
> > > KVM would need to do _something_ in response to impossible situations where
> > > userspace has a removed a feature that was consumed as parted of nested
> > > VM-Enter.
> > 
> > Another reason why I think this may be needed, but I am not sure:
> > 
> > If kvm_vcpu_after_set_cpuid() is executed while L2 is active,
> > KVM_REQ_RECALC_INTERCEPTS will cause
> > svm_recalc_intercepts()->svm_recalc_instruction_intercepts() in the
> > context of L2. While the svm_clr_intercept() and svm_set_intercept()
> > calls explicitly modify vmcb01, we set and clear
> > VIRTUAL_VMLOAD_VMSAVE_ENABLE_MASK in svm->vmcb->control.virt_ext. So
> > this will set/clear the bit in vmcb02.
> > 
> > I think this is a bug, because we could end up setting
> > VIRTUAL_VMLOAD_VMSAVE_ENABLE_MASK when we shouldn't (e.g. L1 doesn't set
> > in vmcb12, or the X86_FEATURE_V_VMSAVE_VMLOAD is not exposed to L1).
> > 
> > Actually as I am typing this, I believe a separate fix for this is
> > needed. We should be probably setting/clearing
> > VIRTUAL_VMLOAD_VMSAVE_ENABLE_MASK on svm->vmcb01.control.
> > 
> > Did I miss something?
> 
> If the analysis above is correct, then a separate fix is indeed required
> because we can end up in the same situation from
> kvm_vm_ioctl_set_msr_filter() -> KVM_REQ_RECALC_INTERCEPTS.

Ouch.  Yep, svm_recalc_instruction_intercepts() should always operate on vmcb01.