From: Xiaoyao Li <xiaoyao.li@intel.com>
To: Sean Christopherson <seanjc@google.com>
Cc: sashiko-reviews@lists.linux.dev, kvm@vger.kernel.org,
Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [PATCH v2 2/3] KVM: TDX: Fix the exit reason handling
Date: Thu, 13 Aug 2026 16:10:37 +0800 [thread overview]
Message-ID: <e749e9bc-5bdf-4e43-87cf-32b0a58981ea@intel.com> (raw)
In-Reply-To: <an0N0vHwsYEqjpRe@google.com>
On 8/13/2026 8:20 AM, Sean Christopherson wrote:
> On Tue, Aug 11, 2026, Xiaoyao Li wrote:
>> On 8/11/2026 7:57 AM, Sean Christopherson wrote:
>>> On Mon, Aug 10, 2026, Xiaoyao Li wrote:
>>>> On 8/10/2026 7:39 PM, sashiko-bot@kernel.org wrote:
>>>>>> @@ -2147,7 +2156,7 @@ void tdx_get_exit_info(struct kvm_vcpu *vcpu, u32 *reason,
>>>>>> struct vcpu_tdx *tdx = to_tdx(vcpu);
>>>>>> *reason = tdx->vt.exit_reason.full;
>>>>>> - if (*reason != -1u) {
>>>>>> + if (tdx->vt.exit_reason.basic != -1) {
>>>>> [Severity: Medium]
>>>>> Will this check always evaluate to true due to C integer promotion rules?
>>>>>
>>>>> The basic field in union vmx_exit_reason is a 16-bit unsigned bitfield. When
>>>>> comparing it to -1, the unsigned 16-bit value is promoted to a signed 32-bit
>>>>> integer. If the value was set to -1 (65535), the comparison evaluates as
>>>>> 65535 != -1, which is always true.
>>>>>
>>>>
>>>> Well, how about something below on top of this patch?
>>>
>>> No, we need to not rely on magic exit_reason.basic values. Can't this be?
>>>
>>> if ((tdx->vp_enter_ret & TDX_SW_ERROR) != TDX_SW_ERROR) {
>>
>> I think the reason of checking if (*reason != -1u) in the original commit
>> 095b71a03f49 ("KVM: TDX: Add a place holder to handle TDX VM exit") was
>> that, -1u means there is no valid Exit Reason in the lower 32 bits in
>> vp_enter_ret.
>>
>> Change it to check TDX_SW_ERROR, doesn't look correct to me. Set the
>> EPT_MISCONFIG magic handling aside, TDX_SW_ERROR only means the SEAMCALL
>> instruction faults, e.g., hitting #UD, #GP, or VMFAILINVALID. Just a small
>> subset of the cases where there is no valid Exit Reason.
>
> Surely we can enumerate those cases? I.e. why can't that be something like:
>
> if (tdx_is_exit_reason_valid(vcpu))
>
> where tdx_is_exit_reason_valid() decodes vp_enter_ret. Clobbering the entire
> exit reason and then _relying_ on that clobbered state is gross and brittle.
This a good suggestion. I implemented it as:
Author: Xiaoyao Li <xiaoyao.li@intel.com>
Date: Thu Aug 13 09:42:15 2026 +0800
KVM: TDX: Check if there is valid exit info based on vp_enter_ret
Check if there is valid exit info based on vp_enter_ret instead of
relying
on the clobbered Exit Reason, in tdx_get_exit_info().
Current KVM uses "Exit Reason is not equal to the synthesized invalid
Exit Reason, -1u," as the condition to identify there is a real TD Exit
and valid exit infos. However, there is one issue with this approach:
KVM updates the Exit Reason to the synthesized invalid Exit Reason for
real EPT MISCONFIG as well. This is a false positive that real EPT
MISCONFIG has valid exit infos.
Though the issue can be addressed by changing the handling for real EPT
MISCONFIG to not update the Exit Reason to the synthesized one, relying
on the clobbered Exit Reason itself is brittle. Instead, check
vp_enter_ret directly to identify if it is a valid Exit Reason.
Fixes: da407fe45908 ("KVM: TDX: Handle EPT violation/misconfig exit")
Cc: stable@vger.kernel.org
Suggested-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Xiaoyao Li <xiaoyao.li@intel.com>
diff --git a/arch/x86/kvm/vmx/tdx.c b/arch/x86/kvm/vmx/tdx.c
index 7338ac0af693..f9036c0a8f9c 100644
--- a/arch/x86/kvm/vmx/tdx.c
+++ b/arch/x86/kvm/vmx/tdx.c
@@ -921,21 +921,27 @@ static __always_inline u32
tdcall_to_vmx_exit_reason(struct kvm_vcpu *vcpu)
return EXIT_REASON_TDCALL;
}
-static __always_inline u32 tdx_to_vmx_exit_reason(struct kvm_vcpu *vcpu)
+static __always_inline bool tdx_is_exit_reason_valid(u64 vp_enter_ret)
{
- struct vcpu_tdx *tdx = to_tdx(vcpu);
- u32 exit_reason;
-
- switch (tdx->vp_enter_ret & TDX_SEAMCALL_STATUS_MASK) {
+ switch (vp_enter_ret & TDX_SEAMCALL_STATUS_MASK) {
case TDX_SUCCESS:
case TDX_NON_RECOVERABLE_VCPU:
case TDX_NON_RECOVERABLE_TD:
case TDX_NON_RECOVERABLE_TD_NON_ACCESSIBLE:
case TDX_NON_RECOVERABLE_TD_WRONG_APIC_MODE:
- break;
+ return true;
default:
- return -1u;
+ return false;
}
+}
+
+static __always_inline u32 tdx_to_vmx_exit_reason(struct kvm_vcpu *vcpu)
+{
+ struct vcpu_tdx *tdx = to_tdx(vcpu);
+ u32 exit_reason;
+
+ if (!tdx_is_exit_reason_valid(tdx->vp_enter_ret))
+ return -1u;
exit_reason = tdx->vp_enter_ret;
@@ -2144,7 +2150,7 @@ void tdx_get_exit_info(struct kvm_vcpu *vcpu, u32
*reason,
struct vcpu_tdx *tdx = to_tdx(vcpu);
*reason = tdx->vt.exit_reason.full;
- if (*reason != -1u) {
+ if (tdx_is_exit_reason_valid(tdx->vp_enter_ret)) {
*info1 = vmx_get_exit_qual(vcpu);
*info2 = tdx->ext_exit_qualification;
*intr_info = vmx_get_intr_info(vcpu);
next prev parent reply other threads:[~2026-08-13 8:10 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-10 11:21 [PATCH v2 0/3] KVM: TDX: Enable VM-DoS Prevention Features for TDX Xiaoyao Li
2026-08-10 11:21 ` [PATCH v2 1/3] KVM: TDX: Enable Notify VM exit Xiaoyao Li
2026-08-11 0:37 ` Edgecombe, Rick P
2026-08-10 11:21 ` [PATCH v2 2/3] KVM: TDX: Fix the exit reason handling Xiaoyao Li
2026-08-10 11:39 ` sashiko-bot
2026-08-10 12:02 ` Xiaoyao Li
2026-08-10 23:57 ` Sean Christopherson
2026-08-11 0:04 ` Sean Christopherson
2026-08-12 3:20 ` Xiaoyao Li
2026-08-12 12:28 ` Xiaoyao Li
2026-08-11 0:19 ` Xiaoyao Li
2026-08-13 0:20 ` Sean Christopherson
2026-08-13 8:10 ` Xiaoyao Li [this message]
2026-08-11 0:03 ` Sean Christopherson
2026-08-11 3:17 ` Xiaoyao Li
2026-08-11 17:36 ` Sean Christopherson
2026-08-11 0:38 ` Edgecombe, Rick P
[not found] ` <6bb1328d-e995-4ad7-9744-3ab01d2ae591@intel.com>
2026-08-11 15:20 ` Edgecombe, Rick P
2026-08-12 7:29 ` Xiaoyao Li
2026-08-12 20:21 ` Edgecombe, Rick P
2026-08-13 0:16 ` Sean Christopherson
2026-08-13 8:34 ` Xiaoyao Li
2026-08-10 11:22 ` [PATCH v2 3/3] KVM: TDX: Enable Bus Lock VM exit Xiaoyao Li
2026-08-10 11:46 ` sashiko-bot
2026-08-10 12:03 ` Xiaoyao Li
2026-08-11 1:18 ` Edgecombe, Rick P
2026-08-11 1:44 ` Xiaoyao Li
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=e749e9bc-5bdf-4e43-87cf-32b0a58981ea@intel.com \
--to=xiaoyao.li@intel.com \
--cc=kvm@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=sashiko-reviews@lists.linux.dev \
--cc=seanjc@google.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