Re: Drop "KVM: TDX: Handle TDG.VP.VMCALL<GetTdVmCallInfo> hypercall"

[Binbin Wu <binbin.wu@linux.intel.com>]

On 4/23/2025 10:09 PM, Paolo Bonzini wrote:
> On Sat, Apr 19, 2025 at 12:16 AM Edgecombe, Rick P
> <rick.p.edgecombe@intel.com> wrote:
>> TDG.VP.VMCALL<INSTRUCTION.WBINVD> - Missing
>> TDG.VP.VMCALL<INSTRUCTION.PCONFIG> - Missing
> WBINVD and PCONFIG need to be implemented (PCONFIG can be a stub).
>
>> TDG.VP.VMCALL<Service.Query> - Missing
>> TDG.VP.VMCALL<Service.MigTD> - Missing
> Service needs to be implemented and return Unsupported (0xFFFFFFFE)
> for all services.
>
>> TDG.VP.VMCALL<GETQUOTE> - Have patches, but missing
>> TDG.VP.VMCALL<SETUPEVENTNOTIFYINTERRUPT> - Have patches, but missing
> These two need to be supported by userspace and one could say that
> (therefore) GetTdVmCallInfo would also have to be implemented by
> userspace. This probably is a good idea in general to leave the door
> open to more GetTdVmCallInfo leaves.
>
> In order to make it easy for userspace to implement GetQuote, it would
> be nice to have a status for Unsupported
> listed for GetQuote, because they need to add it anyway for future tdvcalls
>
> SetupEventNotifyInterrupt can be a stub if GetQuote is unsupported;
> therefore it's also trivial for userspace to implement it if the specs
> adds the "unsupported" return code for GetQuote.

IIUC, there are two things:
1. Add a "unsupported" status code to GHCI spec and list "unsupported" as the
    possible return code for GetQuote.
2. Userspace still needs handle the exit reason due to GetQuote and
    SetupEventNotifyInterrupt. But Userspace has two choices:
    - To have a full implementation for GetQuote, and also a full implementation
      for SetupEventNotifyInterrupt.
    - Just return "unsupported" for GetQuote, and the handling for
      SetupEventNotifyInterrupt can be a stub.

It is correct?

>
>> Xiaoyao was tossing around the idea of adding a dedicated "not implemented"
>> return code too. It could make it simpler to evolve the GHCI spec vs the all or
>> nothing approach. To me, the main finding here is that we need to have more
>> clarity on how the GHCI will evolve going forward.
> I agree that both of these are independently useful, the main action
> item for KVM being to move TdVmCallInfo to userspace

Implementing GetTdVmCallInfo in userspace is helpful only when there is GHCI
spec update, i.e., userspace is able to return the bitmaps for supported
TDVMCALLs, right?

Before the GHCI is changed, can we just leave the implementation of
GetTdVmCallInfo as it is or we want the userspace to implement GetTdVmCallInfo
now?


>   and add support
> for the other two userspace TDCALLs.
>
> Adding WBINVD/PCONFIG/Service is also something that has to be done,
> but less urgent since nobody is using them.
>
>
> Paolo
>
>