The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
To: "Li, Xiaoyao" <xiaoyao.li@intel.com>,
	"pbonzini@redhat.com" <pbonzini@redhat.com>,
	"seanjc@google.com" <seanjc@google.com>
Cc: "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"linux-coco@lists.linux.dev" <linux-coco@lists.linux.dev>,
	"kas@kernel.org" <kas@kernel.org>,
	"nik.borisov@suse.com" <nik.borisov@suse.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 3/3] KVM: TDX: Enable Bus Lock VM exit
Date: Tue, 11 Aug 2026 01:18:45 +0000	[thread overview]
Message-ID: <fd9498858696baf30ab5b151f79fcf173d0fb0cd.camel@intel.com> (raw)
In-Reply-To: <20260810112200.2326727-4-xiaoyao.li@intel.com>

On Mon, 2026-08-10 at 19:22 +0800, Xiaoyao Li wrote:
> 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.

A bit run-on to me. Why not break it up like it's explained in patch 1.

> 
> 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.
> Clear the bus_lock_detected bit to avoid being counted multiple times if
> it needs to return early for wait_for_sept_zap case in tdx_vcpu_run().
> Since the wait_for_sept_zap case is expected to be rare, just do the
> clearing of bus_lock_detected unconditionally.
> 
> Note, there is no enumeration bit for this feature by TDX module because
> all TDX modules support it, and allow to set the TD VMCS as long as the
> hardware supports the feature.
> 
> 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>
> ---
> Changes in v2:
> - Don't overwrite the negative return value to 0. (Sashiko)
> - Clear the bus_lock_detected bit when it returns early for
>   wait_for_sept_zap case.
> - Add a note to clarify the feature is always supported by the TDX
>   module, to make Sashiko happy.

Ha! This is probably just being a bit funny. But let's treat AI review as
suggestions only. If it is a good feedback, it can stand on it's own.

> ---
>  arch/x86/kvm/vmx/tdx.c | 28 ++++++++++++++++++++++++++--
>  arch/x86/kvm/vmx/vmx.c |  2 +-
>  arch/x86/kvm/vmx/vmx.h |  1 +
>  3 files changed, 28 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/x86/kvm/vmx/tdx.c b/arch/x86/kvm/vmx/tdx.c
> index a89885d550c9..ac3f71643cd5 100644
> --- a/arch/x86/kvm/vmx/tdx.c
> +++ b/arch/x86/kvm/vmx/tdx.c
> @@ -1080,8 +1080,10 @@ fastpath_t tdx_vcpu_run(struct kvm_vcpu *vcpu, u64 run_flags)
>  	 * allowing vCPU entry to avoid contention with tdh_vp_enter() and
>  	 * TDCALLs.
>  	 */
> -	if (unlikely(READ_ONCE(to_kvm_tdx(vcpu->kvm)->wait_for_sept_zap)))
> +	if (unlikely(READ_ONCE(to_kvm_tdx(vcpu->kvm)->wait_for_sept_zap))) {
> +		vt->exit_reason.bus_lock_detected = 0;
>  		return EXIT_FASTPATH_EXIT_HANDLED;
> +	}

Hmm. Why is this the only part of exit_reason that we care about in this
scenario?

I went and looked for similar scenarios on the VMX side to see what it did, and
didn't find any. Same for you?

>  
>  	trace_kvm_entry(vcpu, run_flags & KVM_RUN_FORCE_IMMEDIATE_EXIT);
>  
> @@ -2037,7 +2039,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;
> @@ -2138,6 +2140,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 __vmx_handle_notify(vcpu, vmx_get_exit_qual(vcpu));
> +	case EXIT_REASON_BUS_LOCK:
> +		return handle_bus_lock_vmexit(vcpu);
>  	default:
>  		break;
>  	}
> @@ -2147,6 +2151,22 @@ 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;
> +			ret = 0;
> +		}
> +
> +		vcpu->run->flags |= KVM_RUN_X86_BUS_LOCK;
> +	}
> +	return ret;
> +}

Ok, so the plan is to consolidate this duplication on top of the backportable
fix.

> +
>  void tdx_get_exit_info(struct kvm_vcpu *vcpu, u32 *reason,
>  		u64 *info1, u64 *info2, u32 *intr_info, u32 *error_code)
>  {
> @@ -3173,6 +3193,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 e53cc96002c7..c429db9b9205 100644
> --- a/arch/x86/kvm/vmx/vmx.c
> +++ b/arch/x86/kvm/vmx/vmx.c
> @@ -6265,7 +6265,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 dc8517f15bc4..8faf04c09721 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);
>  
>  static inline void vmx_disable_intercept_for_msr(struct kvm_vcpu *vcpu,
>  						 u32 msr, int type)


  reply	other threads:[~2026-08-11  1:18 UTC|newest]

Thread overview: 11+ 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-11  0:03   ` Sean Christopherson
2026-08-11  3:17     ` Xiaoyao Li
2026-08-11  0:38   ` Edgecombe, Rick P
2026-08-11  1:32     ` Xiaoyao Li
2026-08-10 11:22 ` [PATCH v2 3/3] KVM: TDX: Enable Bus Lock VM exit Xiaoyao Li
2026-08-11  1:18   ` Edgecombe, Rick P [this message]
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=fd9498858696baf30ab5b151f79fcf173d0fb0cd.camel@intel.com \
    --to=rick.p.edgecombe@intel.com \
    --cc=kas@kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-coco@lists.linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nik.borisov@suse.com \
    --cc=pbonzini@redhat.com \
    --cc=seanjc@google.com \
    --cc=xiaoyao.li@intel.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