[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <61e8b41970f0feddef3d6c3114d40ae8e4992784.camel@intel.com>
Date: Tue, 27 Aug 2024 20:40:58 +0000
From: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To: "kvm@...r.kernel.org" <kvm@...r.kernel.org>, "pbonzini@...hat.com"
<pbonzini@...hat.com>, "nik.borisov@...e.com" <nik.borisov@...e.com>,
"seanjc@...gle.com" <seanjc@...gle.com>
CC: "Li, Xiaoyao" <xiaoyao.li@...el.com>, "tony.lindgren@...ux.intel.com"
<tony.lindgren@...ux.intel.com>, "Huang, Kai" <kai.huang@...el.com>,
"isaku.yamahata@...il.com" <isaku.yamahata@...il.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 21/25] KVM: x86: Introduce KVM_TDX_GET_CPUID
On Tue, 2024-08-27 at 15:19 +0300, Nikolay Borisov wrote:
> >
> > But beyond checking for supported features, there are also bug fixes that
> > can
> > affect usability. In the NO_RBP_MOD case we need a specific recent TDX
> > module in
> > order to remove the RBP workaround patches.
>
> My point was that if having the NO_RPB_MOD implied that the CPUID
> 0x8000000 configuration capability is also there (not that there is a
> direct connection between the too but it seems the TDX module isn't
> being updated that often, I might be wrong of course!), there is no
> point in having the workaround as NO_RPB_MOD is the minimum required
> version.
Having NO_RBP_MOD won't imply 0x80000008 configuration capability. We will have
to check for a new feature bit for that. We should wait until it's finalized to
add the code.
Powered by blists - more mailing lists