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

[Xiaoyao Li <xiaoyao.li@intel.com>]

On 6/11/2025 10:04 AM, Binbin Wu wrote:
> 
> 
> On 6/11/2025 12:54 AM, Edgecombe, Rick P wrote:
>> On Tue, 2025-06-10 at 09:50 -0700, Rick Edgecombe wrote:
>>> 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.
> 
> The opt-in interface can eliminate some requirements for userspace.
> E.g, for GetQuote, this patch set enforces userspace to handle the exit 
> reason
> due to GetQuote as the initial support, because KVM doesn't know if 
> userspace
> is able to handle the exit reason or not without userspace's opt-in, unless
> it's handled by default in userspace.

Beside it.

opt-in is not needed if we only care about <getquote> for now since KVM 
makes <getquote> exit to userspace unconditionally.

But to support any new TDVMCALL leaf that needs to exit userspace, we 
will have to use opt-in. So to me, implement the opt-in at the first 
place as a common interface for all the optional tdvmcall leafs instead 
of making <getquote> specific is not a bad idea to me, especially the 
opt-in implementation doesn't look complicated.

>>>   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.
> 
> Maybe we can use a TDX specific opt-in interface instead of TDVMCALL 
> specific
> interface.
> But not sure we should add it now or later.

For simplicity, I prefer separate opt-in interfaces, it makes code simpler.