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

[Xiaoyao Li]

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.