Received-SPF: pass (google.com: domain of linux-kernel+bounces-170508-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Date: Mon, 6 May 2024 16:33:17 -0700
In-Reply-To: <038379acaf26dd942a744290bde0fc772084dbe9.camel@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>
 <e39f609f-314b-43c7-b297-5c01e90c023a@intel.com> <038379acaf26dd942a744290bde0fc772084dbe9.camel@intel.com>
Message-ID: <ZjlovaBlLicFb6Z_@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: Rick P Edgecombe <rick.p.edgecombe@intel.com>
Cc: Weijiang Yang <weijiang.yang@intel.com>, Chao Gao <chao.gao@intel.com>, 
	Dave Hansen <dave.hansen@intel.com>, "x86@kernel.org" <x86@kernel.org>, 
	"peterz@infradead.org" <peterz@infradead.org>, "john.allen@amd.com" <john.allen@amd.com>, 
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "mlevitsk@redhat.com" <mlevitsk@redhat.com>, 
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>, "pbonzini@redhat.com" <pbonzini@redhat.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

On Mon, May 06, 2024, Rick P Edgecombe wrote:
> On Mon, 2024-05-06 at 17:19 +0800, Yang, Weijiang wrote:
> > On 5/2/2024 7:15 AM, Sean Christopherson wrote:
> > > On Sun, Feb 18, 2024, Yang Weijiang wrote:
> > > > @@ -696,6 +697,20 @@ void kvm_set_cpu_caps(void)
> > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0kvm_cpu_cap_set(X86_FEATURE_INTEL_STIBP);
> > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0if (boot_cpu_has(X8=
6_FEATURE_AMD_SSBD))
> > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0kvm_cpu_cap_set(X86_FEATURE_SPEC_CTRL_SSBD);
> > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0/*
> > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * Don't use boot_cpu_ha=
s() to check availability of IBT because
> > > > the
> > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * feature bit is cleare=
d in boot_cpu_data when ibt=3Doff is applied
> > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * in host cmdline.
> > > I'm not convinced this is a good reason to diverge from the host kern=
el.=C2=A0
> > > E.g.  PCID and many other features honor the host setup, I don't see =
what
> > > makes IBT special.
> >=20
> > This is mostly based on our user experience and the hypothesis for clou=
d
> > computing: When we evolve host kernels, we constantly encounter issues =
when
> > kernel IBT is on, so we have to disable kernel IBT by adding ibt=3Doff.=
 But
> > we need to test the CET features in VM, if we just simply refer to host
> > boot cpuid data, then IBT cannot be enabled in VM which makes CET featu=
res
> > incomplete in guest.
> >=20
> > I guess in cloud computing, it could run into similar dilemma. In this
> > case, the tenant cannot benefit the feature just because of host SW
> > problem. I know currently KVM except LA57 always honors host feature
> > configurations, but in CET case, there could be divergence wrt honoring
> > host configuration as long as there's no quirk for the feature.
> >=20
> > But I think the issue is still open for discussion...
>=20
> I think the back and forth I remembered was actually around SGX IBT, but =
I did
> find this thread:
> https://lore.kernel.org/lkml/20231128085025.GA3818@noisy.programming.kick=
s-ass.net/
>=20
> Disabling kernel IBT enforcement without disabling KVM IBT seems worthwhi=
le. But
> the solution is to not to not honor host support. It is to have kernel IB=
T not
> clear the feature flag and instead clear something else. This can be done
> independently of the KVM series.

Hmm, I don't disagree, but I'm not sure it makes sense to wait on that disc=
ussion
to exempt IBT from the "it must be supported in the host" rule.  I suspect =
that
tweaking the handling X86_FEATURE_IBT of will open a much larger can of wor=
ms,
as overhauling feature flag handling is very much on the x86 maintainers to=
do
list.

IMO, the odds of there being a hardware bug that necessitates hard disablin=
g IBT
are lower than the odds of KVM support for CET landing well before the feat=
ure
stuff is sorted out.