linux-kernel - Re: [PATCH v12 20/23] KVM: selftests: Add support for TDX TDCALL from guest

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aQTdTkMIukzt-YlA@google.com>
Date: Fri, 31 Oct 2025 09:01:18 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Ira Weiny <ira.weiny@...el.com>
Cc: Sagi Shahar <sagis@...gle.com>, linux-kselftest@...r.kernel.org, 
	Paolo Bonzini <pbonzini@...hat.com>, Shuah Khan <shuah@...nel.org>, 
	Ackerley Tng <ackerleytng@...gle.com>, Ryan Afranji <afranji@...gle.com>, 
	Andrew Jones <ajones@...tanamicro.com>, Isaku Yamahata <isaku.yamahata@...el.com>, 
	Erdem Aktas <erdemaktas@...gle.com>, Rick Edgecombe <rick.p.edgecombe@...el.com>, 
	Roger Wang <runanwang@...gle.com>, Binbin Wu <binbin.wu@...ux.intel.com>, 
	Oliver Upton <oliver.upton@...ux.dev>, "Pratik R. Sampat" <pratikrajesh.sampat@....com>, 
	Reinette Chatre <reinette.chatre@...el.com>, Chao Gao <chao.gao@...el.com>, 
	Chenyi Qiang <chenyi.qiang@...el.com>, linux-kernel@...r.kernel.org, kvm@...r.kernel.org
Subject: Re: [PATCH v12 20/23] KVM: selftests: Add support for TDX TDCALL from guest

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