Re: [PATCH v2 13/29] KVM: nSVM: Add a placeholder ASID for L2

[Yosry Ahmed <yosry@kernel.org>]

On Thu, Oct 08, 2026 at 12:42:00AM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] kvm/svm: SEV migration leaves vmcb01 without SEV flags if in guest mode
> --
> 
> commit a990122c49d4a9878fc605ac4ab62f79ce50bdad
> Author: Yosry Ahmed <yosry@kernel.org>
> 
> KVM: nSVM: Add a placeholder ASID for L2
> 
> This commit introduces a placeholder ASID for L2 that is initially the same
> as L1's ASID to facilitate future ASID separation. It also updates SEV VM
> migration to copy the new SEV ASID into asid02 and vmcb02 if nested is
> already initialized on the destination vCPU.
> 
> [ ... ]
> 
> > diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
> > index 99577859e1aab..b2e6acfbb081f 100644
> > --- a/arch/x86/kvm/svm/sev.c
> > +++ b/arch/x86/kvm/svm/sev.c
> > @@ -2041,6 +2041,15 @@ static void sev_vcpu_migrate_asid(struct vcpu_svm *dst_svm,
> >  	 */
> >  	free_asid(dst_svm->asid);
> >  	dst_svm->asid = asid;
> > +
> > +	/*
> > +	 * If nested is already initialized on the destination vCPU, also update
> > +	 * the nested ASID to match the new SEV ASID.
> > +	 */
> > +	if (dst_svm->nested.vmcb02.ptr) {
> > +		dst_svm->nested.asid02 = asid;
> > +		dst_svm->nested.vmcb02.ptr->control.asid = asid;
> > +	}
> >  }
> >  
> >  static void sev_migrate_from(struct kvm *dst_kvm, struct kvm *src_kvm)
> 
> [Severity: High]
> Does this migration path leave vmcb01 without SEV flags if the destination
> vCPU is in guest mode?
> 
> During SEV migration, sev_migrate_from() calls sev_init_vmcb() shortly after
> sev_vcpu_migrate_asid() updates the ASID:
> 
> arch/x86/kvm/svm/sev.c:sev_migrate_from() {
>     ...
> 		sev_vcpu_migrate_asid(dst_svm, dst->asid);
> 		sev_init_vmcb(dst_svm, false);
>     ...
> }
> 
> If userspace restores nested state before the migration ioctl, the vCPU could
> be in guest mode with svm->vmcb pointing to vmcb02.
> 
> In this scenario, sev_init_vmcb() modifies svm->vmcb, effectively leaving
> vmcb01 uninitialized for SEV:
> 
> arch/x86/kvm/svm/sev.c:sev_init_vmcb() {
>     ...
> 	svm->vmcb->control.misc_ctl |= SVM_MISC_ENABLE_SEV;
> 	clr_exception_intercept(svm, UD_VECTOR);
> 
> 	WARN_ON_ONCE(svm->asid != sev_get_asid(vcpu->kvm));
> 	svm->vmcb->control.asid = svm->asid;
>     ...
> }
> 
> When the vCPU exits nested mode, it will run L1 as a normal (non-SEV) guest.
> Since KVM still expects an SEV/SEV-ES guest (is_sev_es_guest() is true), KVM
> will skip loading guest state but the hardware will execute vmcb01 as a normal
> guest. Can this cause a guest crash or hypervisor confusion (e.g. unexpected
> intercepts triggering KVM warnings)?
> 
> Should the migration path ensure vmcb01 is updated with the SEV flags and
> new ASID regardless of whether the vCPU is currently in nested guest mode?

This seems like a pre-existing issue. sev_init_vmcb() (and some of its
callees) already operate on the current VMCB, which would be vmcb02 if
the vCPU is in guest mode.

This series (but not this patch, but patch 7) adds another
initialization in the current VMCB to sev_init_vmcb(), which arguably
makes things a bit worse, but it's already broken.

So I am leaning to not doing anything in this series, and migrating SEV
vCPUs in guest mode (or disallowing that?) can be done separately
if/when needed.

> 
> -- 
> Sashiko AI review · https://sashiko.dev/#/patchset/20261008001425.2458927-1-yosry@kernel.org?part=13