Re: [RFC PATCH 3/4] KVM: TDX: Exit to userspace for GetTdVmCallInfo

[Edgecombe, Rick P]

On Tue, 2025-06-10 at 17:16 +0800, Xiaoyao Li wrote:
> >     A new KVM exit reason KVM_EXIT_TDX_GET_TDVMCALL_INFO and its structure
> >     are added. Userspace is required to handle the exit reason as the
> > initial
> >     support for TDX.
> 
> It doesn't look like a good and correct design.
> 
> Consider the case that userspace supports SetupEventNotifyInterrupt and 
> returns bit 1 of leaf_output[0] as 1 to KVM, and KVM returns it to TD 
> guest for TDVMCALL_GET_TD_VM_CALL_INFO. So TD guest treats it as 
> SetupEventNotifyInterrupt is support. But when TD guest issues this 
> TDVMCALL, KVM doesn't support the exit to userspace for this specific 
> leaf and userspace doesn't have chance to handle it.

Why do we need an opt-in interface instead of a way to expose which exit's are
supported by KVM? I would think the need for a TDVMCALL opt-in interface would
only come up if there was a bad guest that was making TDVMCALLs that it did not
see in GetTdVmCallInfo. So that we would actually require an opt-in is not
guaranteed. 

Another consideration could be how to handle GetQuote for an eventual TDVMCALL
opt-in interface, should it be needed. The problem would be GetQuote would be
opted in by default and make the interface weird. But we may not want to have a
TDVMCall specific opt-in interface. There could be other TDX behaviors that we
need to opt-in around. In which case the opt-in interface could be more generic,
and by implementing the TDVMCall opt-in interface ahead of time we would end up
with two opt-in interfaces instead of one.

So how about just adding a field to struct kvm_tdx_capabilities to describe the
KVM TDVMcalls? Or some other place? But don't invent an opt-in interface
until/if we need it.