mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Xiaoyao Li <xiaoyao.li@intel.com>
To: Binbin Wu <binbin.wu@linux.intel.com>,
	rick.p.edgecombe@intel.com, pbonzini@redhat.com,
	seanjc@google.com
Cc: kvm@vger.kernel.org, kai.huang@intel.com,
	adrian.hunter@intel.com, reinette.chatre@intel.com,
	tony.lindgren@intel.com, isaku.yamahata@intel.com,
	yan.y.zhao@intel.com, mikko.ylinen@linux.intel.com,
	linux-kernel@vger.kernel.org, kirill.shutemov@intel.com,
	jiewen.yao@intel.com
Subject: Re: [RFC PATCH 3/4] KVM: TDX: Exit to userspace for GetTdVmCallInfo
Date: Wed, 11 Jun 2025 10:17:53 +0800	[thread overview]
Message-ID: <7f17ca58-5522-45de-9dae-6a11b1041317@intel.com> (raw)
In-Reply-To: <671f2439-1101-4729-b206-4f328dc2d319@linux.intel.com>

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.


  reply	other threads:[~2025-06-11  2:18 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-10  2:14 [RFC PATCH 0/4] TDX attestation support and GHCI fixup Binbin Wu
2025-06-10  2:14 ` [RFC PATCH 1/4] KVM: TDX: Add new TDVMCALL status code for unsupported subfuncs Binbin Wu
2025-06-10  2:14 ` [RFC PATCH 2/4] KVM: TDX: Handle TDG.VP.VMCALL<GetQuote> Binbin Wu
2025-06-10  2:14 ` [RFC PATCH 3/4] KVM: TDX: Exit to userspace for GetTdVmCallInfo Binbin Wu
2025-06-10  9:16   ` Xiaoyao Li
2025-06-10 16:50     ` Edgecombe, Rick P
2025-06-10 16:54       ` Edgecombe, Rick P
2025-06-11  2:04         ` Binbin Wu
2025-06-11  2:37           ` Xiaoyao Li
2025-06-11 14:17             ` Edgecombe, Rick P
2025-06-11 14:34               ` Xiaoyao Li
2025-06-11 14:41                 ` Edgecombe, Rick P
2025-06-11  1:37     ` Binbin Wu
2025-06-11  2:17       ` Xiaoyao Li [this message]
2025-06-11 14:54         ` Sean Christopherson
2025-06-11 14:58           ` Edgecombe, Rick P
2025-06-11 16:26             ` Sean Christopherson
2025-06-11 16:53               ` Edgecombe, Rick P
2025-06-11 18:13                 ` Sean Christopherson
2025-06-11 18:52                   ` Edgecombe, Rick P
2025-06-12  8:27                   ` Huang, Kai
2025-06-12 15:26                     ` Edgecombe, Rick P
2025-06-20 18:27                   ` Edgecombe, Rick P
2025-06-10  2:14 ` [RFC PATCH 4/4] KVM: TDX: Check KVM exit on KVM_HC_MAP_GPA_RANGE when TD finalize Binbin Wu
2025-06-10 17:01   ` Edgecombe, Rick P
2025-06-10 19:58     ` Sean Christopherson
2025-06-11  1:22       ` Binbin Wu
2025-06-11 13:36         ` Sean Christopherson
2025-06-11 14:01           ` Xiaoyao Li
2025-06-11 14:04             ` Edgecombe, Rick P
2025-06-11 14:26               ` Xiaoyao Li
2025-06-11 16:00                 ` Binbin Wu
2025-06-11 15:33           ` Binbin Wu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7f17ca58-5522-45de-9dae-6a11b1041317@intel.com \
    --to=xiaoyao.li@intel.com \
    --cc=adrian.hunter@intel.com \
    --cc=binbin.wu@linux.intel.com \
    --cc=isaku.yamahata@intel.com \
    --cc=jiewen.yao@intel.com \
    --cc=kai.huang@intel.com \
    --cc=kirill.shutemov@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mikko.ylinen@linux.intel.com \
    --cc=pbonzini@redhat.com \
    --cc=reinette.chatre@intel.com \
    --cc=rick.p.edgecombe@intel.com \
    --cc=seanjc@google.com \
    --cc=tony.lindgren@intel.com \
    --cc=yan.y.zhao@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®