Re: [RFC PATCH v2 08/25] KVM: SEV: Stop using per-vCPU ASID for SEV VMs

[Sean Christopherson <seanjc@google.com>]

On Tue, Jul 07, 2026, Yosry Ahmed wrote:
> On Tue, Jun 16, 2026 at 10:50 AM Yosry Ahmed <yosry@kernel.org> wrote:
> > On Mon, Jun 15, 2026 at 6:06 PM <sashiko-bot@kernel.org> wrote:
> > > > diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
> > > > --- a/arch/x86/kvm/svm/sev.c
> > > > +++ b/arch/x86/kvm/svm/sev.c
> > > > @@ -3555,10 +3555,7 @@ int pre_sev_run(struct vcpu_svm *svm, int cpu)
> > > >       if (!cpumask_test_cpu(cpu, to_kvm_sev_info(kvm)->have_run_cpus))
> > > >               cpumask_set_cpu(cpu, to_kvm_sev_info(kvm)->have_run_cpus);
> > > >
> > > > -     /* Assign the asid allocated with this SEV guest */
> > > > -     svm->asid = asid;
> > > > -
> > > > -     if (unlikely(svm->asid != svm->vmcb->control.asid)) {
> > > > +     if (WARN_ON_ONCE(asid != svm->vmcb->control.asid)) {
> > >
> > > [Severity: High]
> > > Can a malicious SEV guest or an unprivileged host-userspace process trigger
> > > this warning by entering nested virtualization or via KVM_SET_NESTED_STATE?
> > >
> > > KVM does not strictly prohibit userspace from exposing CPUID.SVM to an SEV
> > > guest. If an SEV guest sets EFER.SVME and executes VMRUN, KVM intercepts it
> > > and handles the nested transition via nested_svm_vmrun(), which switches the
> > > active VMCB pointer to the nested vmcb02.
> > >
> > > The nested vmcb02 does not inherit the SEV ASID assignment from
> > > sev_init_vmcb(), and its control.asid is initialized separately. During the
> > > subsequent svm_vcpu_run() -> pre_sev_run() call, the VM's valid SEV ASID will
> > > no longer match the nested vmcb02's ASID, causing this warning to trigger.
> >
> > Hmm I looked around the code and I can't see what prevents SEV guests
> > from setting EFER_SVME or using KVM_SET_NESTED_STATE. However, I think
> > a VMRUN from an SEV VM will fail, at least due to not being able to
> > read the vmcb12 from guest memory?
> >
> > That being said, I can drop this stopgap if preferred, I was going to
> > drop it before sending but I left it in just to be cautious.
> 
> From an offline discussion with Sean, seems like it's technically
> possible to actually run nested in SEV. 

It is, past me actually got it working (I was curious). :-)

> So I need to actually handle this in this series, by making sure L2 uses the
> same ASID as L1 (required for SEV), and always flushing that ASID on nested
> transitions. I will also drop this stopgap, given that it's likely that using
> the wrong ASID will result in a loud failure anyway.

FWIW, "need" is debatable.  If supporting nested+SEV adds a lot of complexity,
I'd probably be ok dropping support for that, e.g. by failing VMRUN with a software
error.  But if it's roughly the same complexity overall, I'd probably vote to
allow it, mainly to avoid making semi-arbitrary support/policy decisions in KVM.