Received-SPF: pass (google.com: domain of linux-kernel+bounces-143000-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: Fri, 12 Apr 2024 09:01:52 -0700
In-Reply-To: <CALMp9eR6-7va0XUbEYFNVtGdEzmWbAr9pXhLgSL=f9dJyAso7Q@mail.gmail.com>
Precedence: bulk
Mime-Version: 1.0
References: <20240126085444.324918-1-xiong.y.zhang@linux.intel.com>
 <20240126085444.324918-19-xiong.y.zhang@linux.intel.com> <ZhhUyk2uAXqG7GEd@google.com>
 <CALMp9eR6-7va0XUbEYFNVtGdEzmWbAr9pXhLgSL=f9dJyAso7Q@mail.gmail.com>
Message-ID: <Zhla8NGvQgzhkclx@google.com>
Subject: Re: [RFC PATCH 18/41] KVM: x86/pmu: Intercept full-width GP counter
 MSRs by checking with perf capabilities
From: Sean Christopherson <seanjc@google.com>
To: Jim Mattson <jmattson@google.com>
Cc: Xiong Zhang <xiong.y.zhang@linux.intel.com>, pbonzini@redhat.com, 
	peterz@infradead.org, mizhang@google.com, kan.liang@intel.com, 
	zhenyuw@linux.intel.com, dapeng1.mi@linux.intel.com, kvm@vger.kernel.org, 
	linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org, 
	zhiyuan.lv@intel.com, eranian@google.com, irogers@google.com, 
	samantha.alt@intel.com, like.xu.linux@gmail.com, chao.gao@intel.com, 
	Xiong Zhang <xiong.y.zhang@intel.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Apr 11, 2024, Jim Mattson wrote:
> On Thu, Apr 11, 2024 at 2:23=E2=80=AFPM Sean Christopherson <seanjc@googl=
e.com> wrote:
> >
> > On Fri, Jan 26, 2024, Xiong Zhang wrote:
> > > From: Mingwei Zhang <mizhang@google.com>
> > >
> > > Intercept full-width GP counter MSRs in passthrough PMU if guest does=
 not
> > > have the capability to write in full-width. In addition, opportunisti=
cally
> > > add a warning if non-full-width counter MSRs are also intercepted, in=
 which
> > > case it is a clear mistake.
> > >
> > > Co-developed-by: Xiong Zhang <xiong.y.zhang@intel.com>
> > > Signed-off-by: Xiong Zhang <xiong.y.zhang@intel.com>
> > > Signed-off-by: Mingwei Zhang <mizhang@google.com>
> > > ---
> > >  arch/x86/kvm/vmx/pmu_intel.c | 10 +++++++++-
> > >  1 file changed, 9 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/arch/x86/kvm/vmx/pmu_intel.c b/arch/x86/kvm/vmx/pmu_inte=
l.c
> > > index 7f6cabb2c378..49df154fbb5b 100644
> > > --- a/arch/x86/kvm/vmx/pmu_intel.c
> > > +++ b/arch/x86/kvm/vmx/pmu_intel.c
> > > @@ -429,6 +429,13 @@ static int intel_pmu_set_msr(struct kvm_vcpu *vc=
pu, struct msr_data *msr_info)
> > >       default:
> > >               if ((pmc =3D get_gp_pmc(pmu, msr, MSR_IA32_PERFCTR0)) |=
|
> > >                   (pmc =3D get_gp_pmc(pmu, msr, MSR_IA32_PMC0))) {
> > > +                     if (is_passthrough_pmu_enabled(vcpu) &&
> > > +                         !(msr & MSR_PMC_FULL_WIDTH_BIT) &&
> > > +                         !msr_info->host_initiated) {
> > > +                             pr_warn_once("passthrough PMU never int=
ercepts non-full-width PMU counters\n");
> > > +                             return 1;
> >
> > This is broken, KVM must be prepared to handle WRMSR (and RDMSR and RDP=
MC) that
> > come in through the emulator.
>=20
> Don't tell me that we are still supporting CPUs that don't have
> "unrestricted guest"! Sigh.

Heh, KVM still supports CPUs without VMX virtual NMIs :-)

Practically speaking, if we want to eliminate things like emulated WRMSR/RD=
MSR,
a Kconfig to build a reduced emulator would be the way to go.  But while a =
reduced
emulator would be nice for host security, I don't think it would buy us muc=
h from
a code perspective, since KVM still needs to handle host userspace MSR acce=
sses.

E.g. KVM could have conditional sanity checks for MSRs that are supposed to=
 be
passed through, but unless a reduced emulator is a hard requirement for pas=
sthrough
PMUs, we'd still need the code to handle the emulated accesses.  And even i=
f a
reduced emulator were a hard requirement, I'd still push for a WARN-and-con=
tinue
approach, not a "inject a bogus #GP because KVM screwed up" approach.