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

[Yosry Ahmed]

On Mon, Jul 27, 2026 at 5:36 PM Yosry Ahmed <yosry@xxxxxxxxxx> 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 <yosry@xxxxxxxxxx>
> ---
>  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.

>         svm->nested.initialized = true;
>         return 0;