From: Sean Christopherson <seanjc@google.com>
To: Hao Zhang <hao_zhang_kdev@163.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>, kvm@vger.kernel.org
Subject: Re: [PATCH] KVM: VMX: Complete pending nested VM-Enter on invalid-state failure
Date: Mon, 20 Jul 2026 08:19:30 -0700 [thread overview]
Message-ID: <al48gqBHiZgmVc0v@google.com> (raw)
In-Reply-To: <al3Qbq-jUYE-_72N@192.168.1.215>
On Mon, Jul 20, 2026, Hao Zhang wrote:
> From: Hao Zhang <zhanghao1@kylinos.cn>
> Date: Fri, 17 Jul 2026 09:18:31 +0800
>
> Commit 2bb8cafea80b ("KVM: vVMX: signal failure for nested VMEntry if
> emulation_required") made KVM synthesize a failed VM-Entry with
> EXIT_REASON_INVALID_STATE when L2 guest state requires invalid-state
> emulation during nested VM-Enter.
>
> That synthetic failure is generated in vmx_vcpu_run() before attempting
> hardware VM-Enter. As a result, it returns before the normal post-run
> path that accounts and clears nested_run_pending after a real
> VM-Enter/VM-Exit round trip.
>
> If the synthetic invalid-state failure happens while a nested VM-Enter is
> pending, __vmx_handle_exit() observes a trusted pending nested VM-Enter
> and fires KVM_BUG_ON(), causing KVM_RUN to fail with -EIO instead of
> reflecting the failed VM-Entry to L1.
This KVM_BUG_ON() is working as intended. prepare_vmcs02() is supposed to guard
against emulating VMLAUNCH/VMRESUME with invalid guest state.
Ugh this appears to be reachable by clobbering SMRAM state prior to a RSM to L2.
Is that how you triggered the KVM_BUG_ON()? If so, I'd much figure out a way to
fix the RSM flow. Or maybe just treat those runs as untrusted? Because for all
intents and purposes, stuffing vCPU state via SMRAM is the same as stuffing vCPU
state via KVM ioctls.
diff --git arch/x86/kvm/svm/svm.c arch/x86/kvm/svm/svm.c
index 8c5018c65dc5..1f4604a9ae58 100644
--- arch/x86/kvm/svm/svm.c
+++ arch/x86/kvm/svm/svm.c
@@ -5091,7 +5091,7 @@ static int svm_leave_smm(struct kvm_vcpu *vcpu, const union kvm_smram *smram)
goto unmap_save;
ret = 0;
- vcpu->arch.nested_run_pending = KVM_NESTED_RUN_PENDING;
+ vcpu->arch.nested_run_pending = KVM_NESTED_RUN_PENDING_UNTRUSTED;
unmap_save:
kvm_vcpu_unmap(vcpu, &map_save);
diff --git arch/x86/kvm/vmx/vmx.c arch/x86/kvm/vmx/vmx.c
index e4b9ac7fed9f..5c410f68a716 100644
--- arch/x86/kvm/vmx/vmx.c
+++ arch/x86/kvm/vmx/vmx.c
@@ -8453,7 +8453,7 @@ int vmx_leave_smm(struct kvm_vcpu *vcpu, const union kvm_smram *smram)
if (ret != NVMX_VMENTRY_SUCCESS)
return 1;
- vcpu->arch.nested_run_pending = KVM_NESTED_RUN_PENDING;
+ vcpu->arch.nested_run_pending = KVM_NESTED_RUN_PENDING_UNTRUSTED;
vmx->nested.smm.guest_mode = false;
}
return 0;
prev parent reply other threads:[~2026-07-20 15:19 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-20 7:38 [PATCH] KVM: VMX: Complete pending nested VM-Enter on invalid-state failure Hao Zhang
2026-07-20 15:19 ` Sean Christopherson [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=al48gqBHiZgmVc0v@google.com \
--to=seanjc@google.com \
--cc=hao_zhang_kdev@163.com \
--cc=kvm@vger.kernel.org \
--cc=pbonzini@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox