Re: [PATCH v2 5/6] KVM: x86: Track available/dirty register masks as "unsigned long" values
From: Xiaoyao Li
Date: Wed Apr 15 2026 - 07:32:21 EST
On 4/14/2026 10:04 PM, Sean Christopherson wrote:
On Tue, Apr 14, 2026, Xiaoyao Li wrote:
On 4/14/2026 7:03 AM, Huang, Kai wrote:
Because VMX and SVM make all GRPs available immediately, exceptJust want to understand:
for RSP, KVM ignores avail/dirty for GPRs. I.e. "fixing" TDX will just shift the
"bugs" elsewhere.
I thought the fix could be we simply remove the wrong GPRs from the list.
Not sure how fixing TDX will shift bugs elsewhere?
I'm curious too.
What I'm saying is that, _if_ there are bugs where KVM uses a register that isn't
available, then modifying TDX's list won't actually fix anything (without more
changes), it will just change which code is technically buggy (hence all the quotes
above).
More importantly, because the TDX-Module*requires* RCX (the GPR that holds theHmm I think RCX conveys the shared GPRs and VMM can read. Per "Table 5.323:
mask of registers to expose to the VMM) to be hidden on TDVMCALL, KVM*can't*
do any kind of meaningful "available" tracking.
TDH.VP.ENTER Output Operands Format #5 Definition: On TDCALL(TDG.VP.VMCALL)
Following a TD Entry":
RCX ...
Bit(s) Name Description
31:0 PARAMS_MASK Value as passed into TDCALL(TDG.VP.VMCALL) by
the guest TD: indicates which part of the guest
TD GPR and XMM state is passed as-is to the
VMM
and back. For details, see the description of
TDG.VP.VMCALL in 5.5.26.
I think the problem is, as said previously, currently KVM TDX code uses
KVM's existing infrastructure to emulate MSR, KVM hypercall etc, but
TDVMCALL has a different ABI, thus there's a mismatch here.
I once had patch for it internally.
It adds back the available check for GPRs when accessing instead of assuming
they are always available. For normal VMX and SVM, all the GPRs are still
always available. But for TDX, only EXIT_INFO_1 and EXIT_INFO_2 are always
marked available, while others need to be explicitly set case by case.
The good thing is it makes TDX safer that KVM won't consume invalid data
silently for TDX. But it adds additional overhead of checking the
unnecessary register availability for VMX and SVM case.
-----------------------------&<-------------------------------------
From: Xiaoyao Li <xiaoyao.li@xxxxxxxxx>
Date: Tue, 11 Mar 2025 07:13:29 -0400
Subject: [PATCH] KVM: x86: Add available check for GPRs
Since commit de3cd117ed2f ("KVM: x86: Omit caching logic for
always-available GPRs"), KVM doesn't check the availability of GPRs
except RSP and RIP when accessing them, because they are always
available.
However, it's not true when it comes to TDX. The GPRs are not available
after TD vcpu exits actually.
And it relies on KVM manually sets the
GPRs value when needed, e.g.
- setting rax, rbx, rcx, rdx, rsi, for hypercall emulation in
tdx_emulate_tdvmall();
- setting rax, rcx and rdx before MSR write emulation;
Add the available check of GPRs read, and WARN_ON_ONCE() when unavailable.
It can help capture the cases of undesired GPRs consumption by TDX.
Sorry, but NAK. I am strongly against adding any code to the GPR accessors/mutators
just for TDX. It's a _lot_ of code. From commit de3cd117ed2f ("KVM: x86: Omit
caching logic for always-available GPRs"):
E.g. on x86_64, kvm_emulate_cpuid() is reduced from 342 to 182 bytes and
kvm_emulate_hypercall() from 1362 to 1143, with the total size of KVM
dropping by ~1000 bytes. With CONFIG_RETPOLINE=y, the numbers are even
more pronounced, e.g.: 353->182, 1418->1172 and well over 2000 bytes.
yeah. I had the same feeling that bring up the reduced overhead is not acceptable.
Note that updating only the "available" masks is wrong, as TDX needs to marshall
written registers back to their correct location.
In what case it needs to marshall written registers back? Can you elaborate?
In the end, the available/dirty tracking isn't about hardening against bugs, it's
about deferring expensive VMREAD and VMWRITE (and guest memory) operations until
action is required.
We could bury sanity checks behind a Kconfig of some kind, but I genuinely don't
see much value in doing so. These emulation flows are very static (all register
usage is hardcoded), and so it's very much a "get it right once" sort of thing,
i.e. the odds of a runtime check finding a bug after initial development are
basically zero.
The initial purpose of writing the code was to find if any case/path in KVM that consumes the GPRs for TDX unexpectedly. Not only for the hypercall/MSR emulation paths. There are lots of paths in KVM consuming the GPRs. It's difficult to aduit every path to ensure either a) it won't be reachable by TDX or b) KVM syncs the valid data to the GPRs before accessed by TDX.
An alternative for TDX would be to avoid bouncing through GPRs in the first place,
e.g. by reworking __kvm_emulate_rdmsr() to not access any registers. But I'm
probably opposed to even that, because I doubt the end result would be an overall
net positive for KVM. We'd end up with duplicate code, harder to read common
code (because of the new abstractions), and likely without meaningfully moving
the needle in terms of finding/preventing bugs. KVM still needs to get operands
to/from the right parameters, though only difference is that for TDX, the parameters
would be very "direct".