[PATCH 0/2] KVM: TDX: Enable VM-DoS Prevention Features for TDX

[PATCH 0/2] KVM: TDX: Enable VM-DoS Prevention Features for TDX

[Xiaoyao Li]

There are 3 existing DoS prevention features that can be used by
KVM/Linux to prevent DoS attacks from guests.

1. Bus Lock VM Exit

This feature is controlled by KVM. KVM exposes KVM_CAP_X86_BUS_LOCK_EXIT
as the interface for userspace to query support for and enable the
feature. When enabled, a VM exit occurs after the execution of an
instruction that asserts a bus lock. This VM exit is trap-like, meaning
it does not prevent the bus lock from occurring but can detect that one
has occurred. Similarly, there is another bus lock detection feature for
OS usage, where a #DB is raised when a bus lock occurs at CPL > 0. KVM
does not use this feature to detect bus locks from guests, but
virtualizes it for the guest so that the guest can use it to detect bus
locks from its own userspace.

2. Notify VM Exit

This feature is also controlled by KVM. KVM exposes
KVM_CAP_X86_NOTIFY_VMEXIT as the interface for userspace. When enabled,
a VM exit occurs if certain operations prevent the processor from
reaching an instruction boundary within the configured time window.

3. Split Lock Detection

This feature is controlled by the host kernel rather than KVM. When
enabled, a #AC is raised before a split lock can be acquired. Since the
MSR controlling this feature is per-core in scope, KVM does not
virtualize it for guests. As a result, when a guest split lock triggers
a #AC, the exception is unexpected from the guest's perspective. KVM
addresses this by intercepting the #AC and allowing the host to handle it.

For features 1 and 2, support was missed (inadvertently omitted) for TDX
during the initial TDX base support upstreaming. However, KVM still
reports KVM_CAP_X86_BUS_LOCK_EXIT and KVM_CAP_X86_NOTIFY_VMEXIT as
supported even for TDX guests. This means userspace does not receive an
error when attempting to enable these features for TDs, even though they
are not actually being enabled.

For feature 3, KVM cannot intercept #AC from TDs. There was a prior
effort[1] to enlighten the Linux TD guest kernel to handle such #AC.
however, it was not accepted. We are looking at TDX architecture
enhancement to allow intercepting #AC from TDs.

This series therefore focuses on fixing the CAPs reporting issue and
enabling features 1 and 2 for TDX. Specifically, this series adds the
codes to call SEAMCALLs to set the controlling bits for the features in
TD VMCS and implement the corresponding exit handlers.

[1] https://lore.kernel.org/all/20260107134955.3293885-1-xiaoyao.li@intel.com/ 

Xiaoyao Li (2):
  KVM: TDX: Enable Notify VM exit
  KVM: TDX: Enable Bus Lock VM exit

 arch/x86/kvm/vmx/tdx.c | 33 ++++++++++++++++++++++++++++++++-
 arch/x86/kvm/vmx/vmx.c | 25 ++++++++++++++++---------
 arch/x86/kvm/vmx/vmx.h |  2 ++
 3 files changed, 50 insertions(+), 10 deletions(-)


base-commit: 1590cf0329716306e948a8fc29f1d3ee87d3989f
-- 
2.43.0

[PATCH 1/2] KVM: TDX: Enable Notify VM exit

[Xiaoyao Li]

Enable Notify VM exit functionality for TDX guests.

Notify VM exit is an existing feature supported by KVM. Userspace can
enable Notify VM exit through KVM_CAP_X86_NOTIFY_VMEXIT when it's
reported as supported. However, KVM reports the support of this CAP just
based on the hardware capability but doesn't differentiate between VMX
and TDX. This leads to the issue that userspace can enable this cap for
TDX guests without getting an error, but the feature is not actually
enabled because KVM doesn't call the TDX module API to program the
relevant TD VMCS fields.

Enable Notify VM exit for TDX guests by:

  - Invoking TDX module API calls to set NOTIFY_VM_EXITING and Notify
    Window in TD VMCS. It's done in tdx_vcpu_init() where other TD VMCS
    bits are set. Since TDX vCPU cannot be reset, it only needs to be
    configured once when initializing the TDX vCPU.

  - Adding corresponding exit handler for TDX Notify VM Exit.

Note, Notify VM exit can happen when executing the IRET instruction. If
the IRET unblocks the NMI blocking state, bit 12 of the exit qualification
is set. In this case, the VMM needs to restore the "blocked by NMI" state
when it decides to re-enter the guest. For TDX, KVM cannot manage the
GUEST_INTERRUPTIBILITY_INFO and it's TDX module's responsibility to
handle it.

Fixes: 161d34609f9b ("KVM: TDX: Make TDX VM type supported")
Cc: stable@vger.kernel.org
Signed-off-by: Xiaoyao Li <xiaoyao.li@intel.com>
---
The enabling of Notify VM exit was missed in the initial upstreaming of
TDX base support. We suppose the patch needs to be backported to
stable kernels. So, the cc stable is added.
---
 arch/x86/kvm/vmx/tdx.c | 10 ++++++++++
 arch/x86/kvm/vmx/vmx.c | 23 +++++++++++++++--------
 arch/x86/kvm/vmx/vmx.h |  1 +
 3 files changed, 26 insertions(+), 8 deletions(-)

diff --git a/arch/x86/kvm/vmx/tdx.c b/arch/x86/kvm/vmx/tdx.c
index 545b03d9d10b..cdc0d24657ac 100644
--- a/arch/x86/kvm/vmx/tdx.c
+++ b/arch/x86/kvm/vmx/tdx.c
@@ -2129,6 +2129,9 @@ int tdx_handle_exit(struct kvm_vcpu *vcpu, fastpath_t fastpath)
 		 * - If it's not an MSMI, no need to do anything here.
 		 */
 		return 1;
+	case EXIT_REASON_NOTIFY:
+		/* NMI blocking state is handled by TDX module */
+		return __handle_notify(vcpu, false);
 	default:
 		break;
 	}
@@ -3157,6 +3160,13 @@ static int tdx_vcpu_init(struct kvm_vcpu *vcpu, struct kvm_tdx_cmd *cmd)
 	td_vmcs_write64(tdx, POSTED_INTR_DESC_ADDR, __pa(&tdx->vt.pi_desc));
 	td_vmcs_setbit32(tdx, PIN_BASED_VM_EXEC_CONTROL, PIN_BASED_POSTED_INTR);
 
+	if (kvm_notify_vmexit_enabled(vcpu->kvm)) {
+		td_vmcs_setbit32(tdx, SECONDARY_VM_EXEC_CONTROL,
+				 SECONDARY_EXEC_NOTIFY_VM_EXITING);
+		td_vmcs_write32(tdx, NOTIFY_WINDOW,
+				vcpu->kvm->arch.notify_window);
+	}
+
 	tdx->state = VCPU_TD_STATE_INITIALIZED;
 
 	return 0;
diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index cc75feec05da..9c5a7e5c907e 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -6266,20 +6266,22 @@ static int handle_bus_lock_vmexit(struct kvm_vcpu *vcpu)
 	return 1;
 }
 
-static int handle_notify(struct kvm_vcpu *vcpu)
+int __handle_notify(struct kvm_vcpu *vcpu, bool handle_nmi_unblock)
 {
 	unsigned long exit_qual = vmx_get_exit_qual(vcpu);
 	bool context_invalid = exit_qual & NOTIFY_VM_CONTEXT_INVALID;
 
 	++vcpu->stat.notify_window_exits;
 
-	/*
-	 * Notify VM exit happened while executing iret from NMI,
-	 * "blocked by NMI" bit has to be set before next VM entry.
-	 */
-	if (enable_vnmi && (exit_qual & INTR_INFO_UNBLOCK_NMI))
-		vmcs_set_bits(GUEST_INTERRUPTIBILITY_INFO,
-			      GUEST_INTR_STATE_NMI);
+	if (handle_nmi_unblock) {
+		/*
+		 * Notify VM exit happened while executing iret from NMI,
+		 * "blocked by NMI" bit has to be set before next VM entry.
+		 */
+		if (enable_vnmi && (exit_qual & INTR_INFO_UNBLOCK_NMI))
+			vmcs_set_bits(GUEST_INTERRUPTIBILITY_INFO,
+				      GUEST_INTR_STATE_NMI);
+	}
 
 	if (vcpu->kvm->arch.notify_vmexit_flags & KVM_X86_NOTIFY_VMEXIT_USER ||
 	    context_invalid) {
@@ -6292,6 +6294,11 @@ static int handle_notify(struct kvm_vcpu *vcpu)
 	return 1;
 }
 
+static int handle_notify(struct kvm_vcpu *vcpu)
+{
+	return __handle_notify(vcpu, true);
+}
+
 static int vmx_get_msr_imm_reg(struct kvm_vcpu *vcpu)
 {
 	return vmx_get_instr_info_reg(vmcs_read32(VMX_INSTRUCTION_INFO));
diff --git a/arch/x86/kvm/vmx/vmx.h b/arch/x86/kvm/vmx/vmx.h
index dc8517f15bc4..79431b5e9bcb 100644
--- a/arch/x86/kvm/vmx/vmx.h
+++ b/arch/x86/kvm/vmx/vmx.h
@@ -379,6 +379,7 @@ bool __vmx_vcpu_run(struct vcpu_vmx *vmx, unsigned int flags);
 void vmx_ept_load_pdptrs(struct kvm_vcpu *vcpu);
 
 void vmx_set_intercept_for_msr(struct kvm_vcpu *vcpu, u32 msr, int type, bool set);
+int __handle_notify(struct kvm_vcpu *vcpu, bool handle_nmi_unblock);
 
 static inline void vmx_disable_intercept_for_msr(struct kvm_vcpu *vcpu,
 						 u32 msr, int type)
-- 
2.43.0

[PATCH 2/2] KVM: TDX: Enable Bus Lock VM exit

[Xiaoyao Li]

Enable Bus Lock VM exit functionality for TDX guests.

Userspace can enable KVM_BUS_LOCK_DETECTION_EXIT for TDX guests
without getting an error, but the feature is not actually enabled
because KVM does not yet program the TDX execution control or handle
the resulting exit.

Enable Bus Lock VM exit for TDX guests by programming the
BUS_LOCK_DETECTION control in the TD VMCS and by adding the exit
handler.

Fixes: 161d34609f9b ("KVM: TDX: Make TDX VM type supported")
Cc: stable@vger.kernel.org
Originally-by: Chenyi Qiang <chenyi.qiang@intel.com>
Signed-off-by: Xiaoyao Li <xiaoyao.li@intel.com>
---
The enabling of Bus Lock exit was missed in the initial upstreaming of
TDX base support. We suppose the patch needs to be backported to
stable kernels. So, the cc stable is added.

This patch makes the exit handlers for VMX and TDX look similar, we can
actually consolidate them. However, considering this series needs to be
backported to stable kernel while the consolidation patch doesn't need
to, we plan to send the consolidation patch separately after this series
settles.
---
 arch/x86/kvm/vmx/tdx.c | 23 ++++++++++++++++++++++-
 arch/x86/kvm/vmx/vmx.c |  2 +-
 arch/x86/kvm/vmx/vmx.h |  1 +
 3 files changed, 24 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kvm/vmx/tdx.c b/arch/x86/kvm/vmx/tdx.c
index cdc0d24657ac..c037e9cb5bdf 100644
--- a/arch/x86/kvm/vmx/tdx.c
+++ b/arch/x86/kvm/vmx/tdx.c
@@ -2031,7 +2031,7 @@ int tdx_complete_emulated_msr(struct kvm_vcpu *vcpu, int err)
 }
 
 
-int tdx_handle_exit(struct kvm_vcpu *vcpu, fastpath_t fastpath)
+static int __tdx_handle_exit(struct kvm_vcpu *vcpu, fastpath_t fastpath)
 {
 	struct vcpu_tdx *tdx = to_tdx(vcpu);
 	u64 vp_enter_ret = tdx->vp_enter_ret;
@@ -2132,6 +2132,8 @@ int tdx_handle_exit(struct kvm_vcpu *vcpu, fastpath_t fastpath)
 	case EXIT_REASON_NOTIFY:
 		/* NMI blocking state is handled by TDX module */
 		return __handle_notify(vcpu, false);
+	case EXIT_REASON_BUS_LOCK:
+		return handle_bus_lock_vmexit(vcpu);
 	default:
 		break;
 	}
@@ -2141,6 +2143,21 @@ int tdx_handle_exit(struct kvm_vcpu *vcpu, fastpath_t fastpath)
 	return 0;
 }
 
+int tdx_handle_exit(struct kvm_vcpu *vcpu, fastpath_t fastpath)
+{
+	int ret = __tdx_handle_exit(vcpu, fastpath);
+
+	/* Exit to user space when bus lock was detected */
+	if (vmx_get_exit_reason(vcpu).bus_lock_detected) {
+		if (ret > 0)
+			vcpu->run->exit_reason = KVM_EXIT_X86_BUS_LOCK;
+
+		vcpu->run->flags |= KVM_RUN_X86_BUS_LOCK;
+		return 0;
+	}
+	return ret;
+}
+
 void tdx_get_exit_info(struct kvm_vcpu *vcpu, u32 *reason,
 		u64 *info1, u64 *info2, u32 *intr_info, u32 *error_code)
 {
@@ -3167,6 +3184,10 @@ static int tdx_vcpu_init(struct kvm_vcpu *vcpu, struct kvm_tdx_cmd *cmd)
 				vcpu->kvm->arch.notify_window);
 	}
 
+	if (vcpu->kvm->arch.bus_lock_detection_enabled)
+		td_vmcs_setbit32(tdx, SECONDARY_VM_EXEC_CONTROL,
+				 SECONDARY_EXEC_BUS_LOCK_DETECTION);
+
 	tdx->state = VCPU_TD_STATE_INITIALIZED;
 
 	return 0;
diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index 9c5a7e5c907e..c590eb1e06ee 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -6255,7 +6255,7 @@ static int handle_encls(struct kvm_vcpu *vcpu)
 }
 #endif /* CONFIG_X86_SGX_KVM */
 
-static int handle_bus_lock_vmexit(struct kvm_vcpu *vcpu)
+int handle_bus_lock_vmexit(struct kvm_vcpu *vcpu)
 {
 	/*
 	 * Hardware may or may not set the BUS_LOCK_DETECTED flag on BUS_LOCK
diff --git a/arch/x86/kvm/vmx/vmx.h b/arch/x86/kvm/vmx/vmx.h
index 79431b5e9bcb..f2c80e4dc5ac 100644
--- a/arch/x86/kvm/vmx/vmx.h
+++ b/arch/x86/kvm/vmx/vmx.h
@@ -379,6 +379,7 @@ bool __vmx_vcpu_run(struct vcpu_vmx *vmx, unsigned int flags);
 void vmx_ept_load_pdptrs(struct kvm_vcpu *vcpu);
 
 void vmx_set_intercept_for_msr(struct kvm_vcpu *vcpu, u32 msr, int type, bool set);
+int handle_bus_lock_vmexit(struct kvm_vcpu *vcpu);
 int __handle_notify(struct kvm_vcpu *vcpu, bool handle_nmi_unblock);
 
 static inline void vmx_disable_intercept_for_msr(struct kvm_vcpu *vcpu,
-- 
2.43.0

Re: [PATCH 1/2] KVM: TDX: Enable Notify VM exit

[Nikolay Borisov]

On 8/5/26 06:12, Xiaoyao Li wrote:
> Enable Notify VM exit functionality for TDX guests.
> 
> Notify VM exit is an existing feature supported by KVM. Userspace can
> enable Notify VM exit through KVM_CAP_X86_NOTIFY_VMEXIT when it's
> reported as supported. However, KVM reports the support of this CAP just
> based on the hardware capability but doesn't differentiate between VMX
> and TDX. This leads to the issue that userspace can enable this cap for
> TDX guests without getting an error, but the feature is not actually
> enabled because KVM doesn't call the TDX module API to program the
> relevant TD VMCS fields.
> 
> Enable Notify VM exit for TDX guests by:
> 
>    - Invoking TDX module API calls to set NOTIFY_VM_EXITING and Notify
>      Window in TD VMCS. It's done in tdx_vcpu_init() where other TD VMCS
>      bits are set. Since TDX vCPU cannot be reset, it only needs to be
>      configured once when initializing the TDX vCPU.
> 
>    - Adding corresponding exit handler for TDX Notify VM Exit.


nit: That feature is completely misnamed in the kernel. It should be 
instruction timeout (as is in the SDM). Please reword the changelog to 
refer to the name of the features as they are in the SDM. I.e if you 
search for NOTIFY_VMEXIT or NOTIFY_WINDOW absolutely nothing can be 
found in the SDM. The changelog should ideally mention both - SDM's 
nomenclature and linux's nomenclature.
> 
> Note, Notify VM exit can happen when executing the IRET instruction. If
> the IRET unblocks the NMI blocking state, bit 12 of the exit qualification
> is set. In this case, the VMM needs to restore the "blocked by NMI" state
> when it decides to re-enter the guest. For TDX, KVM cannot manage the
> GUEST_INTERRUPTIBILITY_INFO and it's TDX module's responsibility to
> handle it.
> 
> Fixes: 161d34609f9b ("KVM: TDX: Make TDX VM type supported")
> Cc: stable@vger.kernel.org
> Signed-off-by: Xiaoyao Li <xiaoyao.li@intel.com>
> ---
> The enabling of Notify VM exit was missed in the initial upstreaming of
> TDX base support. We suppose the patch needs to be backported to
> stable kernels. So, the cc stable is added.
> ---
>   arch/x86/kvm/vmx/tdx.c | 10 ++++++++++
>   arch/x86/kvm/vmx/vmx.c | 23 +++++++++++++++--------
>   arch/x86/kvm/vmx/vmx.h |  1 +
>   3 files changed, 26 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/x86/kvm/vmx/tdx.c b/arch/x86/kvm/vmx/tdx.c
> index 545b03d9d10b..cdc0d24657ac 100644
> --- a/arch/x86/kvm/vmx/tdx.c
> +++ b/arch/x86/kvm/vmx/tdx.c
> @@ -2129,6 +2129,9 @@ int tdx_handle_exit(struct kvm_vcpu *vcpu, fastpath_t fastpath)
>   		 * - If it's not an MSMI, no need to do anything here.
>   		 */
>   		return 1;
> +	case EXIT_REASON_NOTIFY:
> +		/* NMI blocking state is handled by TDX module */
> +		return __handle_notify(vcpu, false);

I'd rather there be a private handle_tdx_notify function in tdx.c than 
exposing __handle_notify and introducing the boolean. This is needed 
because the TDX module handles the NMI unblocking, so let's keep the 
implementation specific to tdx.

<snip>

Re: [PATCH 1/2] KVM: TDX: Enable Notify VM exit

[Sean Christopherson]

+Chang

On Thu, Aug 06, 2026, Nikolay Borisov wrote:
> On 8/5/26 06:12, Xiaoyao Li wrote:
> > Enable Notify VM exit functionality for TDX guests.
> > 
> > Notify VM exit is an existing feature supported by KVM. Userspace can
> > enable Notify VM exit through KVM_CAP_X86_NOTIFY_VMEXIT when it's
> > reported as supported. However, KVM reports the support of this CAP just
> > based on the hardware capability but doesn't differentiate between VMX
> > and TDX. This leads to the issue that userspace can enable this cap for
> > TDX guests without getting an error, but the feature is not actually
> > enabled because KVM doesn't call the TDX module API to program the
> > relevant TD VMCS fields.
> > 
> > Enable Notify VM exit for TDX guests by:
> > 
> >    - Invoking TDX module API calls to set NOTIFY_VM_EXITING and Notify
> >      Window in TD VMCS. It's done in tdx_vcpu_init() where other TD VMCS
> >      bits are set. Since TDX vCPU cannot be reset, it only needs to be
> >      configured once when initializing the TDX vCPU.
> > 
> >    - Adding corresponding exit handler for TDX Notify VM Exit.
> 
> 
> nit: That feature is completely misnamed in the kernel.

Well that's bloody annoying.  The feature was called "NOTIFY VM EXIT" in the
December 2022 version of the ISE, but indeed is called Instruction Timeout in
the March 2023 versio of the SDM.  Intel isn't exactly building a stellar track
record with ISE publications...

Chang, please forward this to the right people as well.  Changing the name of a
feature isn't the end of the world, but things like this add friction and make
it quite clear that ISEs are very much "pre-production" drafts.  Which is totally
fine, and there is most definitely value in publishing early drafts of features,
but it means I'm going to be very hesitant to merge features in advance of them
being formally defined in the SDM.

> It should be instruction timeout (as is in the SDM). Please reword the
> changelog to refer to the name of the features as they are in the SDM. I.e if
> you search for NOTIFY_VMEXIT or NOTIFY_WINDOW absolutely nothing can be found
> in the SDM.  The changelog should ideally mention both - SDM's nomenclature
> and linux's nomenclature.

No, let's change Linux's nomenclature before merging this, "Notify" was always
vague and confusing.  It's unfortunate that we let that bleed into uAPI headers,
but we can simply #define aliases (or just force userspace to update as well, if
they use kernel headers directly).

Re: [PATCH 1/2] KVM: TDX: Enable Notify VM exit

[Edgecombe, Rick P]

On Thu, 2026-08-06 at 06:50 -0700, Sean Christopherson wrote:
> > It should be instruction timeout (as is in the SDM). Please reword the
> > changelog to refer to the name of the features as they are in the SDM. I.e
> > if you search for NOTIFY_VMEXIT or NOTIFY_WINDOW absolutely nothing can be
> > found in the SDM.  The changelog should ideally mention both - SDM's
> > nomenclature and linux's nomenclature.
> 
> No, let's change Linux's nomenclature before merging this, "Notify" was always
> vague and confusing.  It's unfortunate that we let that bleed into uAPI
> headers, but we can simply #define aliases (or just force userspace to update
> as well, if they use kernel headers directly).

Hmm, ok. We were trying to go with a minimal backport friendly fix.

Xiaoyao, if we are going to carve it up, I guess we might as well do the
consolidation of the exit handlers too on this version. (a cleanup patch that
got left off of this).

Re: [PATCH 1/2] KVM: TDX: Enable Notify VM exit

[Sean Christopherson]

On Fri, Aug 07, 2026, Rick P Edgecombe wrote:
> On Thu, 2026-08-06 at 06:50 -0700, Sean Christopherson wrote:
> > > It should be instruction timeout (as is in the SDM). Please reword the
> > > changelog to refer to the name of the features as they are in the SDM. I.e
> > > if you search for NOTIFY_VMEXIT or NOTIFY_WINDOW absolutely nothing can be
> > > found in the SDM.  The changelog should ideally mention both - SDM's
> > > nomenclature and linux's nomenclature.
> > 
> > No, let's change Linux's nomenclature before merging this, "Notify" was always
> > vague and confusing.  It's unfortunate that we let that bleed into uAPI
> > headers, but we can simply #define aliases (or just force userspace to update
> > as well, if they use kernel headers directly).
> 
> Hmm, ok. We were trying to go with a minimal backport friendly fix.
> 
> Xiaoyao, if we are going to carve it up, I guess we might as well do the
> consolidation of the exit handlers too on this version. (a cleanup patch that
> got left off of this).

Oh, I missed that this was tagged for stable@.  Do the mass rename on top.  To
address Nikolay's concerns, I think a brief blurb at the end calling out that
KVM currently uses old terminology would suffice.  E.g.

  Note, KVM uses "pre-production" terminology for the feature formally called
  Notify VM-Exit.  All public versions of the SDM refer to the feature as
  Instruction Timeout.  This will be remedied in the near future, for now,
  use KVM's terminology for consistency.

Re: [PATCH 1/2] KVM: TDX: Enable Notify VM exit

[Xiaoyao Li]

On 8/6/2026 9:33 PM, Nikolay Borisov wrote:
>> diff --git a/arch/x86/kvm/vmx/tdx.c b/arch/x86/kvm/vmx/tdx.c
>> index 545b03d9d10b..cdc0d24657ac 100644
>> --- a/arch/x86/kvm/vmx/tdx.c
>> +++ b/arch/x86/kvm/vmx/tdx.c
>> @@ -2129,6 +2129,9 @@ int tdx_handle_exit(struct kvm_vcpu *vcpu, 
>> fastpath_t fastpath)
>>            * - If it's not an MSMI, no need to do anything here.
>>            */
>>           return 1;
>> +    case EXIT_REASON_NOTIFY:
>> +        /* NMI blocking state is handled by TDX module */
>> +        return __handle_notify(vcpu, false);
> 
> I'd rather there be a private handle_tdx_notify function in tdx.c than 
> exposing __handle_notify and introducing the boolean. This is needed 
> because the TDX module handles the NMI unblocking, so let's keep the 
> implementation specific to tdx.

The initial version just implemented a separate handler for TDX. It had 
the exact same code as VMX's handle_notify() except the "NMI blocking 
handling". So to eliminate the code duplication, I changed to current code.

Sean, please let me if you have a preference. Otherwise, I'll follow 
Nikolay's preference in a v2.

Re: [PATCH 1/2] KVM: TDX: Enable Notify VM exit

[Xiaoyao Li]

On 8/7/2026 8:32 AM, Sean Christopherson wrote:
> On Fri, Aug 07, 2026, Rick P Edgecombe wrote:
>> On Thu, 2026-08-06 at 06:50 -0700, Sean Christopherson wrote:
>>>> It should be instruction timeout (as is in the SDM). Please reword the
>>>> changelog to refer to the name of the features as they are in the SDM. I.e
>>>> if you search for NOTIFY_VMEXIT or NOTIFY_WINDOW absolutely nothing can be
>>>> found in the SDM.  The changelog should ideally mention both - SDM's
>>>> nomenclature and linux's nomenclature.
>>>
>>> No, let's change Linux's nomenclature before merging this, "Notify" was always
>>> vague and confusing.  It's unfortunate that we let that bleed into uAPI
>>> headers, but we can simply #define aliases (or just force userspace to update
>>> as well, if they use kernel headers directly).
>>
>> Hmm, ok. We were trying to go with a minimal backport friendly fix.
>>
>> Xiaoyao, if we are going to carve it up, I guess we might as well do the
>> consolidation of the exit handlers too on this version. (a cleanup patch that
>> got left off of this).
> 
> Oh, I missed that this was tagged for stable@.  Do the mass rename on top.  To
> address Nikolay's concerns, I think a brief blurb at the end calling out that
> KVM currently uses old terminology would suffice.  E.g.
> 
>    Note, KVM uses "pre-production" terminology for the feature formally called
>    Notify VM-Exit.  All public versions of the SDM refer to the feature as
>    Instruction Timeout.  This will be remedied in the near future, for now,
>    use KVM's terminology for consistency.

Get it. Thanks for writing the blurb! I'll add it in the v2.

Re: [PATCH 1/2] KVM: TDX: Enable Notify VM exit

[Nikolay Borisov]

On 8/7/26 03:32, Sean Christopherson wrote:
> On Fri, Aug 07, 2026, Rick P Edgecombe wrote:
>> On Thu, 2026-08-06 at 06:50 -0700, Sean Christopherson wrote:
>>>> It should be instruction timeout (as is in the SDM). Please reword the
>>>> changelog to refer to the name of the features as they are in the SDM. I.e
>>>> if you search for NOTIFY_VMEXIT or NOTIFY_WINDOW absolutely nothing can be
>>>> found in the SDM.  The changelog should ideally mention both - SDM's
>>>> nomenclature and linux's nomenclature.
>>>
>>> No, let's change Linux's nomenclature before merging this, "Notify" was always
>>> vague and confusing.  It's unfortunate that we let that bleed into uAPI
>>> headers, but we can simply #define aliases (or just force userspace to update
>>> as well, if they use kernel headers directly).
>>
>> Hmm, ok. We were trying to go with a minimal backport friendly fix.
>>
>> Xiaoyao, if we are going to carve it up, I guess we might as well do the
>> consolidation of the exit handlers too on this version. (a cleanup patch that
>> got left off of this).
> 
> Oh, I missed that this was tagged for stable@.  Do the mass rename on top.  To
> address Nikolay's concerns, I think a brief blurb at the end calling out that
> KVM currently uses old terminology would suffice.  E.g.
> 
>    Note, KVM uses "pre-production" terminology for the feature formally called
>    Notify VM-Exit.  All public versions of the SDM refer to the feature as
>    Instruction Timeout.  This will be remedied in the near future, for now,
>    use KVM's terminology for consistency.

That's better, at least it gives pointers what to look for in the SDM.