Received-SPF: pass (google.com: domain of linux-kernel+bounces-135977-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Date: Mon, 8 Apr 2024 15:36:11 -0700
In-Reply-To: <5faaeaa7bc66dbc4ea86a64ef8e8f9b22fd22ef4.camel@intel.com>
Precedence: bulk
Mime-Version: 1.0
References: <20240405165844.1018872-1-seanjc@google.com> <73b40363-1063-4cb3-b744-9c90bae900b5@intel.com>
 <ZhQZYzkDPMxXe2RN@google.com> <a17c6f2a3b3fc6953eb64a0c181b947e28bb1de9.camel@intel.com>
 <ZhQ8UCf40UeGyfE_@google.com> <5faaeaa7bc66dbc4ea86a64ef8e8f9b22fd22ef4.camel@intel.com>
Message-ID: <ZhRxWxRLbnrqwQYw@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>, "kvm@vger.kernel.org" <kvm@vger.kernel.org>, 
	"pankaj.gupta@amd.com" <pankaj.gupta@amd.com>, 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 Mon, Apr 08, 2024, Rick P Edgecombe wrote:
> On Mon, 2024-04-08 at 18:51 +0000, Sean Christopherson wrote:
> > > I'm not following the code examples involving struct kvm_vcpu. Since =
TDX
> > > configures these at a VM level, there isn't a vcpu.
> >=20
> > Ah, I take it GPAW is a VM-scope knob?
>=20
> Yea.
>=20
> > I forget where we ended up with the ordering of TDX commands vs. creati=
ng
> > vCPUs.=C2=A0 Does KVM allow creating vCPU structures in advance of the =
TDX INIT
> > call?=C2=A0 If so, the least awful solution might be to use vCPU0's CPU=
ID.
>=20
> Currently the values for the directly settable CPUID leafs come via a TDX
> specific init VM userspace API.

Is guest.MAXPHYADDR one of those?  If so, use that.

> So should we look at making the TDX side follow a
> KVM_GET_SUPPORTED_CPUID/KVM_SET_CPUID pattern for feature enablement? Or =
am I
> misreading general guidance out of this specific suggestion around GPAW?=
=20

No?  Where I was going with that, is _if_ vCPUs can be created (in KVM) bef=
ore
the GPAW is set (in the TDX module), then using vCPU0's guest.MAXPHYADDR to
compute the desired GPAW may be the least awful solution, all things consid=
ered.