Message-ID: <b003b2c8-66fc-4600-9873-aa5201415b94@intel.com>
Date: Fri, 20 Jun 2025 20:48:39 +0800
From: Xiaoyao Li <xiaoyao.li@...el.com>
To: Paolo Bonzini <pbonzini@...hat.com>
Cc: "Kernel Mailing List, Linux" <linux-kernel@...r.kernel.org>,
 kvm <kvm@...r.kernel.org>, Sean Christopherson <seanjc@...gle.com>,
 Rick Edgecombe <rick.p.edgecombe@...el.com>, "Huang, Kai"
 <kai.huang@...el.com>, Adrian Hunter <adrian.hunter@...el.com>,
 reinette.chatre@...el.com, "Lindgren, Tony" <tony.lindgren@...el.com>,
 "Yamahata, Isaku" <isaku.yamahata@...el.com>, Yan Zhao
 <yan.y.zhao@...el.com>, mikko.ylinen@...ux.intel.com,
 "Shutemov, Kirill" <kirill.shutemov@...el.com>,
 "Yao, Jiewen" <jiewen.yao@...el.com>, Binbin Wu <binbin.wu@...ux.intel.com>
Subject: Re: [PATCH v2 0/3] TDX attestation support and GHCI fixup

On 6/20/2025 8:03 PM, Paolo Bonzini wrote:
> Il ven 20 giu 2025, 03:30 Xiaoyao Li <xiaoyao.li@...el.com> ha scritto:
>>
>> On 6/20/2025 2:01 AM, Paolo Bonzini wrote:
>>> This is a refresh of Binbin's patches with a change to the userspace
>>> API.  I am consolidating everything into a single KVM_EXIT_TDX and
>>> adding to the contract that userspace is free to ignore it *except*
>>> for having to reenter the guest with KVM_RUN.
>>>
>>> If in the future this does not work, it should be possible to introduce
>>> an opt-in interface.  Hopefully that will not be necessary.
>>
>> For <GetTdVmCallInfo> exit, I think KVM still needs to report which
>> TDVMCALL leaf will exit to userspace, to differentiate between different
>> KVMs.
> 
> 
> The interface I chose is that KVM always exits, but it initializes the
> output values such that userspace can leave them untouched for unknown
> TDVMCALLs or unknown leaves. So there is no need for this.
> 
> Querying kernel support of other services can be added later, but
> unless the GHCI adds more input or output fields to TdVmCallInfo there
> is no need to limit the userspace exit to leaf 1.

I meant the case where KVM is going to support another optional TDVMCALL 
leaf in the future, e.g., SetEventNotifyInterrupt. At that time, 
userspace needs to differentiate between old KVM which only supports 
<GetQuote> and new KVM which supports both <GetQuote> and 
<SetEventNotifyInterrupt>.

- If it's old KVM, userspace should only set <GetQuote> bit in 
GetTdVmCallInfo exit. If userspace sets <SetEventNotifyInterrupt> in 
GetTdVmCallInfo exit and enumerate to TD guest, but it's wrong info 
since the KVM doesn't support <SetEventNotifyInterrupt> and userspace 
won't get any chance to handle the guest call of <SetEventNotifyInterrupt>

- But if it's new KVM, userspace can <SetEventNotifyInterrupt> bit in 
GetTdVmCallInfo exit and enumerate to TD guest.

Anyway, its the future problem, there should be various options to 
handle it in the future. This series works for the current need.

> 
> Paolo
> 
>>
>> But it's not a must for current <GetQuote> since it exits to userspace
>> from day 0. So that we can leave the report interface until KVM needs to
>> support user exit of another TDVMCALL leaf.
>>
>>> Paolo
>>>
>>> Binbin Wu (3):
>>>     KVM: TDX: Add new TDVMCALL status code for unsupported subfuncs
>>>     KVM: TDX: Handle TDG.VP.VMCALL<GetQuote>
>>>     KVM: TDX: Exit to userspace for GetTdVmCallInfo
>>>
>>>    Documentation/virt/kvm/api.rst    | 62 ++++++++++++++++++++++++-
>>>    arch/x86/include/asm/shared/tdx.h |  1 +
>>>    arch/x86/kvm/vmx/tdx.c            | 77 ++++++++++++++++++++++++++++---
>>>    include/uapi/linux/kvm.h          | 22 +++++++++
>>>    4 files changed, 154 insertions(+), 8 deletions(-)
>>>
>>
> 

Powered by blists - more mailing lists