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.
