kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Binbin Wu <binbin.wu@linux.intel.com>
To: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>,
	"Li, Xiaoyao" <xiaoyao.li@intel.com>,
	"pbonzini@redhat.com" <pbonzini@redhat.com>,
	"seanjc@google.com" <seanjc@google.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>
Cc: "mikko.ylinen@linux.intel.com" <mikko.ylinen@linux.intel.com>,
	"Huang, Kai" <kai.huang@intel.com>,
	"Yao, Jiewen" <jiewen.yao@intel.com>,
	"Chatre, Reinette" <reinette.chatre@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Zhao, Yan Y" <yan.y.zhao@intel.com>,
	"Lindgren, Tony" <tony.lindgren@intel.com>,
	"Shutemov, Kirill" <kirill.shutemov@intel.com>,
	"Hunter, Adrian" <adrian.hunter@intel.com>,
	"Yamahata, Isaku" <isaku.yamahata@intel.com>
Subject: Re: [RFC PATCH 3/4] KVM: TDX: Exit to userspace for GetTdVmCallInfo
Date: Wed, 11 Jun 2025 10:04:56 +0800	[thread overview]
Message-ID: <e2e7f3d0-1077-44c6-8a1d-add4e1640d32@linux.intel.com> (raw)
In-Reply-To: <d4285aa9adb60b774ca1491e2a0be573e6c82c07.camel@intel.com>



On 6/11/2025 12:54 AM, Edgecombe, Rick P wrote:
> On Tue, 2025-06-10 at 09:50 -0700, Rick Edgecombe wrote:
>> 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.

The opt-in interface can eliminate some requirements for userspace.
E.g, for GetQuote, this patch set enforces userspace to handle the exit reason
due to GetQuote as the initial support, because KVM doesn't know if userspace
is able to handle the exit reason or not without userspace's opt-in, unless
it's handled by default in userspace.

>>   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.

Maybe we can use a TDX specific opt-in interface instead of TDVMCALL specific
interface.
But not sure we should add it now or later.

>>
>> 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.
> Oh, and there already is a hypercall exit opt-in interface, so
> KVM_CAP_TDX_USER_EXIT_TDVMCALL would overlap with it, right?
Not sure what does "overlap" mean here.

They have different namespaces, so they don't impact each other.

Or did you mean it's a duplication both having KVM_CAP_EXIT_HYPERCALL and
KVM_CAP_TDX_USER_EXIT_TDVMCALL?

  reply	other threads:[~2025-06-11  2:05 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 [this message]
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
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=e2e7f3d0-1077-44c6-8a1d-add4e1640d32@linux.intel.com \
    --to=binbin.wu@linux.intel.com \
    --cc=adrian.hunter@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=xiaoyao.li@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;
as well as URLs for NNTP newsgroup(s).