Message-ID: <7f17ca58-5522-45de-9dae-6a11b1041317@intel.com>
Date: Wed, 11 Jun 2025 10:17:53 +0800
From: Xiaoyao Li <xiaoyao.li@...el.com>
To: Binbin Wu <binbin.wu@...ux.intel.com>, rick.p.edgecombe@...el.com,
 pbonzini@...hat.com, seanjc@...gle.com
Cc: kvm@...r.kernel.org, kai.huang@...el.com, adrian.hunter@...el.com,
 reinette.chatre@...el.com, tony.lindgren@...el.com,
 isaku.yamahata@...el.com, yan.y.zhao@...el.com,
 mikko.ylinen@...ux.intel.com, linux-kernel@...r.kernel.org,
 kirill.shutemov@...el.com, jiewen.yao@...el.com
Subject: Re: [RFC PATCH 3/4] KVM: TDX: Exit to userspace for GetTdVmCallInfo

On 6/11/2025 9:37 AM, Binbin Wu wrote:
> 
> 
> On 6/10/2025 5:16 PM, Xiaoyao Li wrote:
>> On 6/10/2025 10:14 AM, Binbin Wu wrote:
>>> Exit to userspace for TDG.VP.VMCALL<GetTdVmCallInfo> via a new KVM exit
>>> reason to allow userspace to provide information about the support of
>>> TDVMCALLs when r12 is 1 for the TDVMCALLs beyond the GHCI base API.
>>>
>>> GHCI spec defines the GHCI base TDVMCALLs: <GetTdVmCallInfo>, <MapGPA>,
>>> <ReportFatalError>, <Instruction.CPUID>, <#VE.RequestMMIO>,
>>> <Instruction.HLT>, <Instruction.IO>, <Instruction.RDMSR> and
>>> <Instruction.WRMSR>. They must be supported by VMM to support TDX 
>>> guests.
>>>
>>> For GetTdVmCallInfo
>>> - When leaf (r12) to enumerate TDVMCALL functionality is set to 0,
>>>    successful execution indicates all GHCI base TDVMCALLs listed 
>>> above are
>>>    supported.
>>>
>>>    Update the KVM TDX document with the set of the GHCI base APIs.
>>>
>>> - When leaf (r12) to enumerate TDVMCALL functionality is set to 1, it
>>>    indicates the TDX guest is querying the supported TDVMCALLs beyond
>>>    the GHCI base TDVMCALLs.
>>>    Exit to userspace to let userspace set the TDVMCALL sub-function 
>>> bit(s)
>>>    accordingly to the leaf outputs.  KVM could set the TDVMCALL bit(s)
>>>    supported by itself when the TDVMCALLs don't need support from 
>>> userspace
>>>    after returning from userspace and before entering guest. 
>>> Currently, no
>>>    such TDVMCALLs implemented, KVM just sets the values returned from
>>>    userspace.
>>>
>>>    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.
> Previously, I also had the idea of setting the information based on 
> userspace's
> opt-ins.
> 
> But for simplicity, this patch set doesn't adopt the opt-in mechanism 
> for KVM
> exit reasons due to TDVMCALLs.
> 
> To resolve the issue you mentions that userspace could set a bit that KVM
> doesn't support the exit to userspace, KVM could mask off the bit(s) not
> supported by KVM before returning back to guest.

silently mask off the value provided from userspace is not a stable ABI 
from userspace perspective. A kvm cap to report what value is 
allowed/supported is still helpful.

> If we agree that it's the right time to have the opt-in, we could go the 
> opt-in
> way and KVM could set the information based on userspace's opt-ins without
> exit to userspace for GetTdVmCallInfo.

Let's see what Paolo and Sean will say.

Powered by blists - more mailing lists