Re: [PATCH v1 26/28] KVM: nSVM: Flush the ASID on nested transitions if shared by L1 and L2

> diff --git a/arch/x86/kvm/svm/nested.c b/arch/x86/kvm/svm/nested.c
> index 58e7d099c559e..9ea8f21be9940 100644
> --- a/arch/x86/kvm/svm/nested.c
> +++ b/arch/x86/kvm/svm/nested.c
> @@ -719,6 +719,15 @@ static void nested_svm_entry_tlb_flush(struct kvm_vcpu *vcpu)
>                 kvm_make_request(KVM_REQ_TLB_FLUSH_GUEST, vcpu);
>         }
>
> +       /*
> +        * If L1 and L2 share the same ASID in hardware (when using the fallback
> +        * ASID for both, or for SEV guests), flush it on nested transitions.
> +        */
> +       if (svm->asid == svm->nested.asid02) {
> +               WARN_ON_ONCE(svm->asid != fallback_asid && !is_sev_guest(vcpu));

From internal Sashiko:
---
Will this WARN_ON_ONCE fire deterministically on the first nested VM-Enter
for normal nested SVM guests?

Because L1 and L2 ASIDs are not properly separated until a later commit in
this series (commit 0fcd2c53996cc885d1e9898202bcd67438d2a97a, "KVM: nSVM:
Use different ASIDs for L1 and L2"), svm->asid and svm->nested.asid02 are
unconditionally equal at this point in the git history.

For a normal nested SVM guest, both svm->asid != fallback_asid and
!is_sev_guest(vcpu) will evaluate to true.

Could an untrusted L1 guest executing VMRUN trigger this warning, potentially
causing a host Denial of Service if panic_on_warn is set? Even though this is
resolved in a later commit, should the WARN_ON_ONCE be deferred until the
ASID separation is actually implemented so that bisectability is preserved and
intermediate commits remain fully self-contained?
---

I don't think a DoS is a risk here, but yeah the warning will fire at
this patch. It should probably be moved till the next patch or a
standalone patch.