All of lore.kernel.org
 help / color / mirror / Atom feed
From: Xiaoyao Li <xiaoyao.li@intel.com>
To: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>,
	"seanjc@google.com" <seanjc@google.com>
Cc: "Gao, Chao" <chao.gao@intel.com>,
	"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
	"kas@kernel.org" <kas@kernel.org>,
	"binbin.wu@linux.intel.com" <binbin.wu@linux.intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"pbonzini@redhat.com" <pbonzini@redhat.com>,
	"nik.borisov@suse.com" <nik.borisov@suse.com>,
	"andrew.cooper3@citrix.com" <andrew.cooper3@citrix.com>
Subject: Re: [PATCH v3 1/4] KVM: TDX: Track configurable CPUID bits allowed by KVM
Date: Thu, 10 Sep 2026 10:53:03 +0800	[thread overview]
Message-ID: <94b3473c-7e44-4f6f-8721-b43ff4e2c423@intel.com> (raw)
In-Reply-To: <c967dc3eb6b128055e415bae45d1c14a52dc4acd.camel@intel.com>

On 9/10/2026 7:18 AM, Edgecombe, Rick P wrote:
> On Wed, 2026-09-09 at 15:29 -0700, Sean Christopherson wrote:
>>   Yeah, *ideally* we'd magically enable everything everywhere all at once.  In
>> reality, different VM types are going to support features at different times. 
>> More importantly, as Xiaoyao points out below in #1, unless we enable
>> everyting in a single patch, which is probably a terrible idea in most cases,
>> we'll still end up with staged/progressive enabling, i.e. we still need to
>> have patches that selectively enable and advertise a feature only for the VM
>> types that actually support the feature.
>>
>> This is all quite similar to Intel and AMD feature enabling being done at
>> different times.  The biggest difference is that Intel and AMD are mutually
>> exclusive and so KVM_GET_SUPPORTED_CPUID always reports the correct
>> information, but TDX already provides KVM_TDX_CAPABILITIES, so AFAICT we still
>> get accurate reporting for TDX, just in a slightly different way.
> I think this actually surfaces another problem with TD-first enabling.
> KVM_TDX_CAPABILITIES only returns the directly configurable bits. Then recall,
> KVM_TDX_GET_CPUID returns the actual TDX module's view of CPUID bits to
> userspace. Then userspace calls KVM_SET_CPUID to actually put them on KVM's vcpu
> so they can match between Qemu, KVM and TDX
> 
> So if a bit is enabled for KVM_TDX_CAPABILITIES, but not yet in
> KVM_GET_SUPPORTED_CPUID. How should userspace interpret KVM_GET_SUPPORTED_CPUID?
> It can ignore it for TDX, but that is how it can find the PV bits today.>
> If we have a TD first feature, it could be a documentation update on how to
> interpret it. Or we could stuff the PV bits somewhere else for TDX and say to
> ignore KVM_GET_SUPPORTED_CPUID for TDX. I think we don't need to solve it before
> we begin filtering like this series has.

The PV bits reported in KVM_GET_SUPPORTED_CPUID are the bits supported for
non-TDX VMs. Only some of them are actually supported for TDX. I would suggest
reporting TDX supported PV CPUIDs in KVM_TDX_CAPABILITIES as well.


  parent reply	other threads:[~2026-09-10  2:53 UTC|newest]

Thread overview: 63+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-27  3:18 [PATCH v3 0/4] KVM: TDX: Validate directly configurable CPUID bits Binbin Wu
2026-08-27  3:18 ` [PATCH v3 1/4] KVM: TDX: Track configurable CPUID bits allowed by KVM Binbin Wu
2026-09-01  6:29   ` Tony Lindgren
2026-09-01  8:23     ` Binbin Wu
2026-09-01  8:27       ` Tony Lindgren
2026-09-01 14:35   ` Xiaoyao Li
2026-09-02  0:33     ` Binbin Wu
2026-09-02 15:09       ` Xiaoyao Li
2026-09-02 16:19         ` Binbin Wu
2026-09-02 16:22           ` Edgecombe, Rick P
2026-09-02 16:25             ` Binbin Wu
2026-09-03  7:28           ` Xiaoyao Li
2026-09-03  8:57             ` Binbin Wu
2026-09-08 21:13             ` Edgecombe, Rick P
2026-09-09 16:39               ` Xiaoyao Li
2026-09-09 22:29                 ` Sean Christopherson
2026-09-09 23:18                   ` Edgecombe, Rick P
2026-09-10  2:39                     ` Binbin Wu
2026-09-10  2:53                     ` Xiaoyao Li [this message]
2026-09-08 21:15         ` Edgecombe, Rick P
2026-08-27  3:18 ` [PATCH v3 2/4] KVM: TDX: Report CORE_CAPABILITIES as configurable Binbin Wu
2026-09-01  6:45   ` Tony Lindgren
2026-09-02 17:43   ` Kishen Maloor
2026-09-03  2:22     ` Binbin Wu
2026-09-03  6:10       ` Kishen Maloor
2026-09-03  8:12         ` Binbin Wu
2026-08-27  3:18 ` [PATCH v3 3/4] KVM: TDX: Filter configurable CPUID bits Binbin Wu
2026-09-01  6:44   ` Tony Lindgren
2026-09-01  8:42     ` Binbin Wu
2026-09-01  9:09       ` Tony Lindgren
2026-09-03  8:04   ` Xiaoyao Li
2026-09-03  8:23     ` Binbin Wu
2026-08-27  3:18 ` [PATCH v3 4/4] KVM: TDX: Validate userspace CPUID input for KVM_TDX_INIT_VM Binbin Wu
2026-08-27  3:24   ` sashiko-bot
2026-08-27  7:25     ` Binbin Wu
2026-09-01  6:47   ` Tony Lindgren
2026-08-27 19:33 ` [PATCH v3 0/4] KVM: TDX: Validate directly configurable CPUID bits Edgecombe, Rick P
2026-08-28  3:19   ` Binbin Wu
2026-08-28 16:58     ` Edgecombe, Rick P
2026-08-31  5:01       ` Binbin Wu
2026-09-01  9:42         ` Xiaoyao Li
2026-09-01 10:21           ` Xiaoyao Li
2026-09-02 16:09           ` Edgecombe, Rick P
2026-09-02 16:21             ` Binbin Wu
2026-09-09  1:46             ` Binbin Wu
2026-09-01  9:38     ` Xiaoyao Li
2026-09-01 17:41       ` Edgecombe, Rick P
2026-09-02 10:29         ` Xiaoyao Li
2026-09-02 13:13           ` Edgecombe, Rick P
2026-09-02 13:39             ` Xiaoyao Li
2026-09-02 13:53               ` Edgecombe, Rick P
2026-09-02 14:21                 ` Xiaoyao Li
2026-09-02 16:26             ` Binbin Wu
2026-09-08  9:42 ` Artem Bityutskiy
2026-09-09  0:04   ` Binbin Wu
2026-09-08 20:30 ` Artem Bityutskiy
2026-09-08 22:31   ` Edgecombe, Rick P
2026-09-09  6:52     ` Artem Bityutskiy
2026-09-09  8:48       ` Binbin Wu
2026-09-09 11:20         ` Artem Bityutskiy
2026-09-10  2:54           ` Binbin Wu
2026-09-08 23:54   ` Binbin Wu
2026-09-09  5:37     ` 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=94b3473c-7e44-4f6f-8721-b43ff4e2c423@intel.com \
    --to=xiaoyao.li@intel.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=binbin.wu@linux.intel.com \
    --cc=chao.gao@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=kas@kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nik.borisov@suse.com \
    --cc=pbonzini@redhat.com \
    --cc=rick.p.edgecombe@intel.com \
    --cc=seanjc@google.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.