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.
