Received-SPF: pass (google.com: domain of linux-kernel+bounces-181346-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Date: Thu, 16 May 2024 09:58:37 -0700
In-Reply-To: <f2d6d62d-09be-4940-9c6e-92f80811587f@intel.com>
Precedence: bulk
Mime-Version: 1.0
References: <20240219074733.122080-1-weijiang.yang@intel.com>
 <20240219074733.122080-25-weijiang.yang@intel.com> <ZjLNEPwXwPFJ5HJ3@google.com>
 <39b95ac6-f163-4461-93f3-eaa653ab1355@intel.com> <ZkYauRJBhaw9P1A_@google.com>
 <f2d6d62d-09be-4940-9c6e-92f80811587f@intel.com>
Message-ID: <ZkY7PblLmWdFYeSa@google.com>
Subject: Re: [PATCH v10 24/27] KVM: x86: Enable CET virtualization for VMX and
 advertise to userspace
From: Sean Christopherson <seanjc@google.com>
To: Dave Hansen <dave.hansen@intel.com>
Cc: Weijiang Yang <weijiang.yang@intel.com>, rick.p.edgecombe@intel.com, 
	pbonzini@redhat.com, x86@kernel.org, kvm@vger.kernel.org, 
	linux-kernel@vger.kernel.org, peterz@infradead.org, chao.gao@intel.com, 
	mlevitsk@redhat.com, john.allen@amd.com
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

On Thu, May 16, 2024, Dave Hansen wrote:
> On 5/16/24 07:39, Sean Christopherson wrote:
> >> We synced the issue internally, and got conclusion that KVM should hon=
or host
> >> IBT config.  In this case IBT bit in boot_cpu_data should be honored.=
=C2=A0 With
> >> this policy, it can avoid CPUID confusion to guest side due to host ib=
t=3Doff
> >> config.
> > What was the reasoning?  CPUID confusion is a weak justification, e.g. =
it's not
> > like the guest has visibility into the host kernel, and raw CPUID will =
still show
> > IBT support in the host.
>=20
> I'm basically arguing for the path of least resistance (at least to start=
).
>=20
> We should just do what takes the least amount of code for now that
> results in mostly sane behavior, then debate about making it perfect late=
r.
>=20
> In other words, let's say the place we'd *IDEALLY* end up is that guests
> can have any random FPU state which is disconnected from the host.  But
> the reality, for now, is that the host needs to have XFEATURE_CET_USER
> set in order to pass it into the guest and that means keeping
> X86_FEATURE_SHSTK set.
>=20
> If you want guest XFEATURE_CET_USER, you must have host
> X86_FEATURE_SHSTK ... for now.

Ah, because fpu__init_system_xstate() will clear XFEATURE_CET_USER via the
X86_FEATURE_SHSTK connection in xsave_cpuid_features.=20

Please put something to that effect in the changelog.  "this literally won'=
t work
(without more changes)" is very different than us making a largely arbitrar=
y
decision.