On Fri, Oct 31, 2025, Sean Christopherson wrote:
On Fri, Oct 31, 2025, Ira Weiny wrote:
Sagi Shahar wrote:
From: Erdem Aktas erdemaktas@google.com
Add support for TDX guests to issue TDCALLs to the TDX module.
Generally it is nice to have more details. As someone new to TDX I have to remind myself what a TDCALL is. And any random kernel developer reading this in the future will likely have even less clue than me.
Paraphrased from the spec:
TDCALL is the instruction used by the guest TD software (in TDX non-root mode) to invoke guest-side TDX functions. TDG.VP.VMCALL helps invoke services from the host VMM.
Add support for TDX guests to invoke services from the host VMM.
Eh, at some point a baseline amount of knowledge is required. I highly doubt regurgitating the spec is going to make a huge difference
I also dislike the above wording, because it doesn't help understand _why_ KVM selftests need to support TDCALL, or _how_ the functionality will be utilized. E.g. strictly speaking, we could write KVM selftests without ever doing a single TDG.VP.VMCALL, because we control both sides (guest and VMM). And I have a hard time belive name-dropping TDG.VP.VMCALL is going to connect the dots between TDCALL and the "tunneling" scheme defined by the GHCI for requesting emulation of "legacy" functionality".
What I would like to know is why selftests are copy-pasting the kernel's scheme for marshalling data to/from the registers used by TDCALL,
I almost forgot. I detest the "throw everything into a structure" approach, which the kernel used largely so that it could share code between SEAMCALLs and TDCALLs. Unless there's a good reason no to, I would much rather have prototypes like
uint64_t __tdvmcall(<all the args>) uint64_t tdvmcall_1(uint64_t arg1); uint64_t tdvmcall_2(uint64_t arg1, uint64_t arg2); uint64_t tdvmcall_3(...); uint65_t tdvmcall_4(...); uint64_t tdvmcall_5(...); uint64_t tdvmcall_6(...);