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

[Yosry Ahmed]

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.