Re: [PATCH v1 12/28] KVM: nSVM: Add a placeholder ASID for L2

On Fri, Jul 31, 2026 at 11:34:34PM -0700, Yosry Ahmed wrote:
> On Mon, Jul 27, 2026 at 5:36 PM Yosry Ahmed <[email protected]> wrote:
> >
> > In preparation for introducing a separate ASID for L2, introduce a
> > 'placeholder' ASID that is still the same as L1's ASID. This will
> > facilitate future changes that need to distinguish L1 and L2's ASIDs,
> > before actually using a different ASID for L1 and L2.
> >
> > No functional change intended.
> >
> > Signed-off-by: Yosry Ahmed <[email protected]>
> > ---
> >  arch/x86/kvm/svm/nested.c | 5 +++--
> >  arch/x86/kvm/svm/svm.h    | 2 ++
> >  2 files changed, 5 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/x86/kvm/svm/nested.c b/arch/x86/kvm/svm/nested.c
> > index ed4af5a08f794..eb60d6b959d86 100644
> > --- a/arch/x86/kvm/svm/nested.c
> > +++ b/arch/x86/kvm/svm/nested.c
> > @@ -698,7 +698,6 @@ static void nested_svm_transition_tlb_flush(struct kvm_vcpu *vcpu)
> >          *  - Honor L1's request to flush an ASID on nested VMRUN
> >          *  - Sync nested NPT MMU on VMRUN that flushes L2's ASID[*]
> >          *  - Don't crush a pending TLB flush in vmcb02 on nested VMRUN
> > -        *  - Flush L1's ASID on KVM_REQ_TLB_FLUSH_GUEST
> >          *
> >          * [*] Unlike nested EPT, SVM's ASID management can invalidate nested
> >          *     NPT guest-physical mappings on VMRUN.
> > @@ -928,7 +927,7 @@ static void nested_vmcb02_prepare_control(struct vcpu_svm *svm)
> >         else
> >                 vmcb02->control.bus_lock_counter = 0;
> >
> > -       vmcb02->control.asid = vmcb01->control.asid;
> > +       vmcb02->control.asid = svm->nested.asid02;
> >
> >         /* Overwritten later if necessary.  */
> >         vmcb_clr_flush_asid(vmcb02);
> > @@ -1498,6 +1497,8 @@ int svm_allocate_nested(struct vcpu_svm *svm)
> >         if (!svm->nested.msrpm)
> >                 goto err_free_vmcb02;
> >
> > +       svm->nested.asid02 = svm->asid;
> > +
> 
> From internal Sashiko:
> ---
> Does caching the ASID here risk leaving nested.asid02 stale during an
> intra-host SEV VM migration?
> 
> If userspace restores EFER.SVME on a destination vCPU before completing
> the migration, svm_allocate_nested() is called and nested.asid02 is
> initialized with a normal non-SEV TLB tag.
> 
> Later, when KVM_CAP_VM_MOVE_ENC_CONTEXT_FROM completes the migration,
> sev_migrate_from() updates the primary ASID but misses this new
> nested.asid02 field:
> 
> arch/x86/kvm/svm/sev.c:sev_migrate_from() {
>         ...
>         dst_svm->asid = dst->asid;
>         sev_init_vmcb(dst_svm, false);
>         ...
> }
> 
> When L1 subsequently executes VMRUN to enter L2,
> nested_vmcb02_prepare_control() will assign this stale non-SEV
> nested.asid02 to vmcb02->control.asid.
> 
> Does this mismatch cause L2 to run with an invalid non-SEV ASID while the
> VMCB's SEV bit is set, resulting in an unconditional #VMEXIT_INVALID
> hardware fault?
> ---
> 
> I am starting to hate SEV..
> 
> This would also be correct if the vCPUs are created on the destination
> VM before it's marked as an SEV VM. This is a recurring theme at this
> point.

So for this problem and the other two SEV migration problems reported in
patch #10, I am thinking we end up with something like this over both
patches (untested) -- any feedback would be appreciated as I have ~0
knowledge of SEV and ~0 testing capabilities:

diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
index 087d18a5eda69..09a0572996352 100644
--- a/arch/x86/kvm/svm/sev.c
+++ b/arch/x86/kvm/svm/sev.c
@@ -2019,6 +2019,29 @@ static void sev_unlock_two_vms(struct kvm *dst_kvm, struct kvm *src_kvm)
        atomic_set_release(&src_sev->migration_in_progress, 0);
 }

+static void sev_vcpu_migrate_asid(struct vcpu_svm *dst_svm, struct vcpu_svm *src_svm,
+                                 unsigned int asid)
+{
+       /*
+        * Free the (potentially non-SEV) ASID on the destination vCPU before
+        * setting the new SEV ASID. Clear the ASID on the source vCPU to avoid
+        * mistakenly attempting to free an SEV ASID after the vCPU is no longer
+        * an SEV vCPU.
+        */
+       free_asid(dst_svm->asid);
+       dst_svm->asid = asid;
+       src_svm->asid = 0;
+
+       /*
+        * If nested is already initialized on the destination vCPU, update the
+        * nested ASID as well 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)
 {
        struct kvm_sev_info *dst = to_kvm_sev_info(dst_kvm);
@@ -2071,12 +2094,6 @@ static void sev_migrate_from(struct kvm *dst_kvm, struct kvm *src_kvm)
        kvm_for_each_vcpu(i, dst_vcpu, dst_kvm) {
                dst_svm = to_svm(dst_vcpu);

-               dst_svm->asid = dst->asid;
-               sev_init_vmcb(dst_svm, false);
-
-               if (!dst->es_active)
-                       continue;
-
                /*
                 * Note, the source is not required to have the same number of
                 * vCPUs as the destination when migrating a vanilla SEV VM.
@@ -2084,6 +2101,12 @@ static void sev_migrate_from(struct kvm *dst_kvm, struct kvm *src_kvm)
                src_vcpu = kvm_get_vcpu(src_kvm, i);
                src_svm = to_svm(src_vcpu);

+               sev_vcpu_migrate_asid(dst_svm, src_svm, dst->asid);
+               sev_init_vmcb(dst_svm, false);
+
+               if (!dst->es_active)
+                       continue;
+
                /*
                 * Transfer VMSA and GHCB state to the destination.  Nullify and
                 * clear source fields as appropriate, the state now belongs to