Re: [PATCH v2 2/3] KVM: TDX: Fix the exit reason handling
Xiaoyao Li <[email protected]>
| Newsgroups | org.kernel.vger.kvm,dev.linux.lists.linux-coco,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
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) {
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.