arch/x86/kvm/vmx/common.h | 20 ++++++++++ arch/x86/kvm/vmx/main.c | 49 ++++++++++++++++++----- arch/x86/kvm/vmx/tdx.c | 82 ++++++++++++++++++++++++++++++--------- arch/x86/kvm/vmx/vmx.c | 46 ++-------------------- 4 files changed, 126 insertions(+), 71 deletions(-)
Hi all,
This is v4 of the series to enable the Notify VM Exit and Bus Lock VM
exit for TDX, which fixes the KVM CAP issue related with them and allow
userspace to actually enable the features.
Compared to v3, this v4 adds 5 more patches. The first 8 patches target
for stable kernels while only the patch 9 doesn't have to. Patch 1 is a
single patch to enable Notify VM exit for TDX. Except patch 6, patch
2-7 are mandatory for enabling Bus Lock VM exit for TDX in patch 8.
Patch 6 itself is a fix for VMX and is OK for cc stable though maybe not
necessary. Patch 6 is added to this series since it can help stop Sashiko
repeating its finding of VMX's pre-existing issue, and it's also necessary
for patch 9 to consilidate the exit handler for VMX and TDX.
There are other issues of existing code found during previous review, like
the EPT MISCONFIG handling. Given they are not mandatory for enabling the
Notify VM exit and Bus Lock VM exit for TDX, the plan is to address them in
a follow-up series separately.
Please refer to v1 for a full background.
v3: https://lore.kernel.org/all/20260812080229.2481439-1-xiaoyao.li@intel.com/
v2: https://lore.kernel.org/all/20260810112200.2326727-1-xiaoyao.li@intel.com/
v1: https://lore.kernel.org/all/20260805031257.1844914-1-xiaoyao.li@intel.com/
Xiaoyao Li (9):
KVM: TDX: Enable Notify VM exit
KVM: TDX: Check if there is valid exit infos based on vp_enter_ret
KVM: TDX: Set bits 31:16 to 0 for the synthesized Exit Reason
KVM: TDX: Don't assume exit_reason[31:16] is all-0 in
tdx_to_vmx_exit_reason()
KVM: TDX: Update exit_reason on wait_for_sept_zap return
KVM: VMX: Preserve negative return value in vmx_handle_exit() with bus
lock detected
KVM: VMX: Make handle_bus_lock_vmexit() a shared helper
KVM: TDX: Enable Bus Lock VM exit
KVM: VMX: Consolidate the exit handler for VMX and TDX
arch/x86/kvm/vmx/common.h | 20 ++++++++++
arch/x86/kvm/vmx/main.c | 49 ++++++++++++++++++-----
arch/x86/kvm/vmx/tdx.c | 82 ++++++++++++++++++++++++++++++---------
arch/x86/kvm/vmx/vmx.c | 46 ++--------------------
4 files changed, 126 insertions(+), 71 deletions(-)
base-commit: 1b731e5ded480bd1e5546aed35584238661ce72e
--
2.43.0
On Wed, 2026-08-19 at 17:48 +0800, Xiaoyao Li wrote: > Patch 6 itself is a fix for VMX and is OK for cc stable though maybe not > necessary. Patch 6 is added to this series since it can help stop Sashiko > repeating its finding of VMX's pre-existing issue, and it's also necessary > for patch 9 to consilidate the exit handler for VMX and TDX. To me this is not a valid reason. Sashiko is great, but we can't let false positives drive the patches. Given that the series is so big now, I'd think it would be better to leave 6 and 9 for follow up, so we can focus on the core thing.
On Wed, Aug 19, 2026, Rick P Edgecombe wrote: > On Wed, 2026-08-19 at 17:48 +0800, Xiaoyao Li wrote: > > Patch 6 itself is a fix for VMX and is OK for cc stable though maybe not > > necessary. Patch 6 is added to this series since it can help stop Sashiko > > repeating its finding of VMX's pre-existing issue, and it's also necessary > > for patch 9 to consilidate the exit handler for VMX and TDX. > > To me this is not a valid reason. Sashiko is great, but we can't let false > positives drive the patches. Given that the series is so big now, I'd think it > would be better to leave 6 and 9 for follow up, so we can focus on the core > thing. Hmm, I disagree. If the consolidation weren't here, I'd absolutely ask for it. This is new feature enabling. Yeah, it happens to be tagged for stable, but at the end of the day, it's new feature enabling. And it's standard operation procedure to do cleanups and dedup code as part of new feature enabling. If anything patch 6 should be patch 1, but that's a minor detail I can sort out when applying (assuming another version isn't required).
On Wed, 2026-08-19 at 16:03 -0700, Sean Christopherson wrote: > > To me this is not a valid reason. Sashiko is great, but we can't let false > > positives drive the patches. Given that the series is so big now, I'd think > > it would be better to leave 6 and 9 for follow up, so we can focus on the > > core thing. > > Hmm, I disagree. If the consolidation weren't here, I'd absolutely ask for > it. This is new feature enabling. Yeah, it happens to be tagged for stable, > but at the end of the day, it's new feature enabling. And it's standard > operation procedure to do cleanups and dedup code as part of new feature > enabling. > > If anything patch 6 should be patch 1, but that's a minor detail I can sort > out when applying (assuming another version isn't required). Ok. But you disagree with dropping the patch? Or that avoiding sashiko reports of existing issues is an invalid reason to change the series? I think it's good to discuss a bit how to handle sashiko scenarios.
On Wed, Aug 19, 2026, Rick P Edgecombe wrote: > On Wed, 2026-08-19 at 16:03 -0700, Sean Christopherson wrote: > > > To me this is not a valid reason. Sashiko is great, but we can't let false > > > positives drive the patches. Given that the series is so big now, I'd think > > > it would be better to leave 6 and 9 for follow up, so we can focus on the > > > core thing. > > > > Hmm, I disagree. If the consolidation weren't here, I'd absolutely ask for > > it. This is new feature enabling. Yeah, it happens to be tagged for stable, > > but at the end of the day, it's new feature enabling. And it's standard > > operation procedure to do cleanups and dedup code as part of new feature > > enabling. > > > > If anything patch 6 should be patch 1, but that's a minor detail I can sort > > out when applying (assuming another version isn't required). > > Ok. But you disagree with dropping the patch? Dropping the patch. > Or that avoiding sashiko reports of existing issues is an invalid reason to > change the series? > > I think it's good to discuss a bit how to handle sashiko scenarios. Like we do any other code review: use common sense and follow established best practices. If a human reviewer pointed out an existing bug, we would analyze the situation and make a judgment call as to whether it's better to send a standalone fix or roll a fix into a new version of the series. If we decided to fix the issue separately, and then a human brought up the same pre-existing issue in a future revision, we would point them at the fix or the previous discussion (or if it was the same human, (politely?) tell them to go away). The only differences is that Sashiko is noisier because is doesn't (yet?) remember what feedback it gave in the past, often doesn't look at the patches later in the series, and doesn't (yet?) respond to emails so telling Sashiko to shut up about a particular pre-existing issue isn't effective. But to be very explicit: don't include a patch *purely* to suppress Sashiko's rediscovery of existing issues.
On 8/19/2026 5:48 PM, Xiaoyao Li wrote: > Hi all, > > This is v4 of the series to enable the Notify VM Exit and Bus Lock VM > exit for TDX, which fixes the KVM CAP issue related with them and allow > userspace to actually enable the features. > > Compared to v3, this v4 adds 5 more patches. The first 8 patches target > for stable kernels while only the patch 9 doesn't have to. Patch 1 is a > single patch to enable Notify VM exit for TDX. Except patch 6, patch > 2-7 are mandatory for enabling Bus Lock VM exit for TDX in patch 8. > > Patch 6 itself is a fix for VMX and is OK for cc stable though maybe not > necessary. Patch 6 is added to this series since it can help stop Sashiko > repeating its finding of VMX's pre-existing issue, and it's also necessary > for patch 9 to consilidate the exit handler for VMX and TDX. > > There are other issues of existing code found during previous review, like > the EPT MISCONFIG handling. Given they are not mandatory for enabling the > Notify VM exit and Bus Lock VM exit for TDX, the plan is to address them in > a follow-up series separately. > > Please refer to v1 for a full background. > > v3: https://lore.kernel.org/all/20260812080229.2481439-1-xiaoyao.li@intel.com/ > v2: https://lore.kernel.org/all/20260810112200.2326727-1-xiaoyao.li@intel.com/ > v1: https://lore.kernel.org/all/20260805031257.1844914-1-xiaoyao.li@intel.com/ Hi Sean, What's your plan on this series? Can you queue it if it looks good to you? Or need me to spin a new version to address Binbin and Rick's comments on the commit message? Thanks, -Xiayao
On Mon, Sep 21, 2026, Xiaoyao Li wrote: > On 8/19/2026 5:48 PM, Xiaoyao Li wrote: > > Hi all, > > > > This is v4 of the series to enable the Notify VM Exit and Bus Lock VM > > exit for TDX, which fixes the KVM CAP issue related with them and allow > > userspace to actually enable the features. > > > > Compared to v3, this v4 adds 5 more patches. The first 8 patches target > > for stable kernels while only the patch 9 doesn't have to. Patch 1 is a > > single patch to enable Notify VM exit for TDX. Except patch 6, patch > > 2-7 are mandatory for enabling Bus Lock VM exit for TDX in patch 8. > > > > Patch 6 itself is a fix for VMX and is OK for cc stable though maybe not > > necessary. Patch 6 is added to this series since it can help stop Sashiko > > repeating its finding of VMX's pre-existing issue, and it's also necessary > > for patch 9 to consilidate the exit handler for VMX and TDX. > > > > There are other issues of existing code found during previous review, like > > the EPT MISCONFIG handling. Given they are not mandatory for enabling the > > Notify VM exit and Bus Lock VM exit for TDX, the plan is to address them in > > a follow-up series separately. > > > > Please refer to v1 for a full background. > > > > v3: https://lore.kernel.org/all/20260812080229.2481439-1-xiaoyao.li@intel.com/ > > v2: https://lore.kernel.org/all/20260810112200.2326727-1-xiaoyao.li@intel.com/ > > v1: https://lore.kernel.org/all/20260805031257.1844914-1-xiaoyao.li@intel.com/ > > Hi Sean, > > What's your plan on this series? Can you queue it if it looks good to you? Or > need me to spin a new version to address Binbin and Rick's comments on the > commit message? Get it applied, with some tweaks. I.e. no v5 necessary.
On 9/22/2026 7:51 AM, Sean Christopherson wrote: > On Mon, Sep 21, 2026, Xiaoyao Li wrote: >> On 8/19/2026 5:48 PM, Xiaoyao Li wrote: >>> Hi all, >>> >>> This is v4 of the series to enable the Notify VM Exit and Bus Lock VM >>> exit for TDX, which fixes the KVM CAP issue related with them and allow >>> userspace to actually enable the features. >>> >>> Compared to v3, this v4 adds 5 more patches. The first 8 patches target >>> for stable kernels while only the patch 9 doesn't have to. Patch 1 is a >>> single patch to enable Notify VM exit for TDX. Except patch 6, patch >>> 2-7 are mandatory for enabling Bus Lock VM exit for TDX in patch 8. >>> >>> Patch 6 itself is a fix for VMX and is OK for cc stable though maybe not >>> necessary. Patch 6 is added to this series since it can help stop Sashiko >>> repeating its finding of VMX's pre-existing issue, and it's also necessary >>> for patch 9 to consilidate the exit handler for VMX and TDX. >>> >>> There are other issues of existing code found during previous review, like >>> the EPT MISCONFIG handling. Given they are not mandatory for enabling the >>> Notify VM exit and Bus Lock VM exit for TDX, the plan is to address them in >>> a follow-up series separately. >>> >>> Please refer to v1 for a full background. >>> >>> v3: https://lore.kernel.org/all/20260812080229.2481439-1-xiaoyao.li@intel.com/ >>> v2: https://lore.kernel.org/all/20260810112200.2326727-1-xiaoyao.li@intel.com/ >>> v1: https://lore.kernel.org/all/20260805031257.1844914-1-xiaoyao.li@intel.com/ >> >> Hi Sean, >> >> What's your plan on this series? Can you queue it if it looks good to you? Or >> need me to spin a new version to address Binbin and Rick's comments on the >> commit message? > > Get it applied, with some tweaks. I.e. no v5 necessary. Thanks!
On Wed, Aug 19, 2026 at 2:59 AM Xiaoyao Li <xiaoyao.li@intel.com> wrote: > > Xiaoyao Li (9): > KVM: TDX: Enable Notify VM exit > KVM: TDX: Check if there is valid exit infos based on vp_enter_ret > KVM: TDX: Set bits 31:16 to 0 for the synthesized Exit Reason > KVM: TDX: Don't assume exit_reason[31:16] is all-0 in > tdx_to_vmx_exit_reason() > KVM: TDX: Update exit_reason on wait_for_sept_zap return > KVM: VMX: Preserve negative return value in vmx_handle_exit() with bus > lock detected > KVM: VMX: Make handle_bus_lock_vmexit() a shared helper > KVM: TDX: Enable Bus Lock VM exit > KVM: VMX: Consolidate the exit handler for VMX and TDX Reviewed-By: Vishal Annapurve <vannapurve@google.com> for the complete series. > > arch/x86/kvm/vmx/common.h | 20 ++++++++++ > arch/x86/kvm/vmx/main.c | 49 ++++++++++++++++++----- > arch/x86/kvm/vmx/tdx.c | 82 ++++++++++++++++++++++++++++++--------- > arch/x86/kvm/vmx/vmx.c | 46 ++-------------------- > 4 files changed, 126 insertions(+), 71 deletions(-) > > > base-commit: 1b731e5ded480bd1e5546aed35584238661ce72e > -- > 2.43.0 > >
On Wed, 19 Aug 2026 17:48:54 +0800, Xiaoyao Li wrote:
> This is v4 of the series to enable the Notify VM Exit and Bus Lock VM
> exit for TDX, which fixes the KVM CAP issue related with them and allow
> userspace to actually enable the features.
>
> Compared to v3, this v4 adds 5 more patches. The first 8 patches target
> for stable kernels while only the patch 9 doesn't have to. Patch 1 is a
> single patch to enable Notify VM exit for TDX. Except patch 6, patch
> 2-7 are mandatory for enabling Bus Lock VM exit for TDX in patch 8.
>
> [...]
Applied to kvm-x86 vmx, thanks!
[1/9] KVM: TDX: Enable Notify VM exit
https://github.com/kvm-x86/linux/commit/d93395058c19
[2/9] KVM: TDX: Check if there is valid exit infos based on vp_enter_ret
https://github.com/kvm-x86/linux/commit/0966c881ea13
[3/9] KVM: TDX: Set bits 31:16 to 0 for the synthesized Exit Reason
https://github.com/kvm-x86/linux/commit/b43c520b198a
[4/9] KVM: TDX: Don't assume exit_reason[31:16] is all-0 in tdx_to_vmx_exit_reason()
https://github.com/kvm-x86/linux/commit/bc335ce04408
[5/9] KVM: TDX: Update exit_reason on wait_for_sept_zap return
https://github.com/kvm-x86/linux/commit/e5f1d62c59ae
[6/9] KVM: VMX: Preserve negative return value in vmx_handle_exit() with bus lock detected
https://github.com/kvm-x86/linux/commit/cef48693da1e
[7/9] KVM: VMX: Make handle_bus_lock_vmexit() a shared helper
https://github.com/kvm-x86/linux/commit/326fa2c9b4d3
[8/9] KVM: TDX: Enable Bus Lock VM exit
https://github.com/kvm-x86/linux/commit/63d196e2e204
[9/9] KVM: VMX: Consolidate the exit handler for VMX and TDX
https://github.com/kvm-x86/linux/commit/213bbf18f07a
--
https://github.com/kvm-x86/linux/tree/next
© 2016 - 2026 Red Hat, Inc.