On Fri, Oct 31, 2025, Sean Christopherson wrote: > On Fri, Oct 31, 2025, Ira Weiny wrote: > > Sagi Shahar wrote: > > > From: Erdem Aktas <[email protected]> > > > > > > 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(...);
