From: Sean Christopherson <seanjc@google.com>
To: Xiaoyao Li <xiaoyao.li@intel.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
Rick Edgecombe <rick.p.edgecombe@intel.com>,
Kiryl Shutsemau <kas@kernel.org>,
Nikolay Borisov <nik.borisov@suse.com>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-coco@lists.linux.dev
Subject: Re: [PATCH v2 2/3] KVM: TDX: Fix the exit reason handling
Date: Tue, 11 Aug 2026 10:36:54 -0700 [thread overview]
Message-ID: <antdtqaEZz5EkZS2@google.com> (raw)
In-Reply-To: <30686bd2-37a4-4cff-82df-29c918444a58@intel.com>
On Tue, Aug 11, 2026, Xiaoyao Li wrote:
> On 8/11/2026 8:03 AM, Sean Christopherson wrote:
> > The shortlog is way too generic, and the changelog is light on details. Over
> > the weekend, I managed to forget why this was necessary, and it took me a few
> > seconds to recall why we need to avoid setting bits 31:16. Of course, one could
> > argue that says as much about me as it does the shortlog+changelog...
> >
> > Oh, and shortlogs like "Fix the exit reason handling" sometimes lead to amusing
> > follow-ups like "Really fix the exit reason handling". Don't be that person :-)
> >
> > Something like:
> >
> > KVM: TDX: Don't clobber exit_reason[31:16] when TDX-Module didn't try VM-Entry
>
> 1. It's not only about clobbering the exit_reason[31:16], but also about how
> to interpret the basic exit, e.g.. the change
>
> - switch (exit_reason) {
> + switch (exit_reason.basic) {
But the current TDX code doesn't care. The switch in tdx_to_vmx_exit_reason()
operates on the raw vp_enter_ret value, not a synthesized/clobbered exit reason.
And the switch in tdx_handle_exit() isn't reachable for the clobbering case
thanks to this check.
if (unlikely(vp_enter_ret == EXIT_REASON_EPT_MISCONFIG)) {
KVM_BUG_ON(1, vcpu->kvm);
return -EIO;
}
I agree that not clobbering exit_reason[31:16] is useful for additional cleanups,
but that isn't the main motiviation for the patch. The precision matters, because
it changes this patch from a "nice to have cleanup" to "this is 100% mandatory to
enable Instruction Timeout VM-Exits on TDX".
> 2. It's not only about TDX module doesn't try VM entry, bus also about a
> valid VM exit after successful VM entry. This patch also preserves the
> exit_reason[31:16] for a valid VM exit. (One could argue that existing code
> cannot clobber exit_reason[31;16] because the code to clobber it requires
> the [31:16] to be 0, because of switch (exit_reason))
>
> 3. For the case where TDX module doesn't try VM-Entry, I'm not sure if
> "clobber" is the correct word. There is no valid exit reason, so nothing to
> be really clobbered. Just don't synthesize a exit reason with non-zero bit
> 31:16.
>
> My intent was just using one patch to handle them all, so as to make KVM
> behave correctly after enabling Bus Lock VM exit for TDX in the next patch.
> Because they are targeted for stable kernels.
>
> What's your advice then? What do you think of spliting it into multiple so
> that it's easier to write a shortlog and changelog for each one.
Heh, my advice is pretty much always the same: when in doubt, split. Squashing
patches together is trivial, disentangling changes after the fact is not.
next prev parent reply other threads:[~2026-08-11 17:36 UTC|newest]
Thread overview: 20+ 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-11 0:19 ` Xiaoyao Li
2026-08-11 0:03 ` Sean Christopherson
2026-08-11 3:17 ` Xiaoyao Li
2026-08-11 17:36 ` Sean Christopherson [this message]
2026-08-11 0:38 ` Edgecombe, Rick P
2026-08-11 1:32 ` Xiaoyao Li
2026-08-11 15:20 ` Edgecombe, Rick P
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=antdtqaEZz5EkZS2@google.com \
--to=seanjc@google.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=rick.p.edgecombe@intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.