Received-SPF: pass (google.com: domain of linux-kernel+bounces-137316-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Date: Tue, 9 Apr 2024 09:26:05 -0700
In-Reply-To: <4ae4769a6f343a2f4d3648e4348810df069f24b7.camel@intel.com>
Precedence: bulk
Mime-Version: 1.0
References: <ZhQZYzkDPMxXe2RN@google.com> <a17c6f2a3b3fc6953eb64a0c181b947e28bb1de9.camel@intel.com>
 <ZhQ8UCf40UeGyfE_@google.com> <5faaeaa7bc66dbc4ea86a64ef8e8f9b22fd22ef4.camel@intel.com>
 <ZhRxWxRLbnrqwQYw@google.com> <957b26d18ba7db611ed6582366066667267d10b8.camel@intel.com>
 <ZhSb28hHoyJ55-ga@google.com> <8b40f8b1d1fa915116ef1c95a13db0e55d3d91f2.camel@intel.com>
 <ZhVdh4afvTPq5ssx@google.com> <4ae4769a6f343a2f4d3648e4348810df069f24b7.camel@intel.com>
Message-ID: <ZhVsHVqaff7AKagu@google.com>
Subject: Re: [ANNOUNCE] PUCK Notes - 2024.04.03 - TDX Upstreaming Strategy
From: Sean Christopherson <seanjc@google.com>
To: Rick P Edgecombe <rick.p.edgecombe@intel.com>
Cc: "davidskidmore@google.com" <davidskidmore@google.com>, Xiaoyao Li <xiaoyao.li@intel.com>, 
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, 
	"srutherford@google.com" <srutherford@google.com>, "pankaj.gupta@amd.com" <pankaj.gupta@amd.com>, 
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>, Isaku Yamahata <isaku.yamahata@intel.com>, 
	Wei W Wang <wei.w.wang@intel.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Apr 09, 2024, Rick P Edgecombe wrote:
> On Tue, 2024-04-09 at 08:23 -0700, Sean Christopherson wrote:
> > > Right, I thought I heard this on the call, and to use the upper bits =
of
> > > that leaf for GPAW. What has changed since then is a little more lear=
ning
> > > on the TDX module behavior around CPUID bits.
> > >=20
> > > The runtime API doesn't provide what the fixed values actually are, b=
ut
> > > per the TDX module folks, which bits are fixed and what the values ar=
e
> > > could change without an opt-in.
> >=20
> > Change when?=C2=A0 While the module is running?=C2=A0 Between modules?
>=20
> Between modules. They are fixed for a specific TDX module version. But th=
e TDX
> module could change.
>=20
> Ah! Maybe there is confusion about where the JSON file is coming from. It=
 is
> *not* coming from the TDX module, it is coming from the Intel site that h=
as the
> documentation to download. It another form of documentation.

I know.

> Haha, if this is the confusion, I see why you reacted that way to "JSON".
> That would be quite the curious choice for a TDX module API.
>=20
> So it is easy to convert it to a C struct and embed it in KVM. It's just =
not
> that useful because it will not necessarily be valid for future TDX modul=
es.

No, I don't want to embed anything in KVM, that's the exact same as hardcod=
ing
crud into KVM, which is what I want to avoid.  I want to be able to roll ou=
t a
new TDX module with any kernel changes, and I want userspace to be able to =
assert
that, for a given TDX module, the effective guest CPUID configuration align=
s with
userspace's desired the vCPU model, i.e. that the value of fixed bits match=
 up
with the guest CPUID that userspace wants to define.

Maybe that just means converting the JSON file into some binary format that=
 the
kernel can already parse.  But I want Intel to commit to providing that met=
adata
along with every TDX module.