Received-SPF: pass (google.com: domain of linux-kernel+bounces-45478-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, 30 Jan 2024 15:27:49 -0800
In-Reply-To: <cce0483f-539b-4be3-838d-af0ec91db8f0@linux.intel.com>
Precedence: bulk
Mime-Version: 1.0
References: <20240109230250.424295-1-seanjc@google.com> <20240109230250.424295-17-seanjc@google.com>
 <5f51fda5-bc07-42ac-a723-d09d90136961@linux.intel.com> <ZaGxNsrf_pUHkFiY@google.com>
 <cce0483f-539b-4be3-838d-af0ec91db8f0@linux.intel.com>
Message-ID: <ZbmF9eM84cQhdvGf@google.com>
Subject: Re: [PATCH v10 16/29] KVM: selftests: Test Intel PMU architectural
 events on gp counters
From: Sean Christopherson <seanjc@google.com>
To: Dapeng Mi <dapeng1.mi@linux.intel.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, 
	Kan Liang <kan.liang@linux.intel.com>, Jim Mattson <jmattson@google.com>, 
	Jinrong Liang <cloudliang@tencent.com>, Aaron Lewis <aaronlewis@google.com>, 
	Like Xu <likexu@tencent.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Jan 15, 2024, Dapeng Mi wrote:
>=20
> On 1/13/2024 5:37 AM, Sean Christopherson wrote:
> > On Fri, Jan 12, 2024, Dapeng Mi wrote:
> > > On 1/10/2024 7:02 AM, Sean Christopherson wrote:
> > > > +/*
> > > > + * If an architectural event is supported and guaranteed to genera=
te at least
> > > > + * one "hit, assert that its count is non-zero.  If an event isn't=
 supported or
> > > > + * the test can't guarantee the associated action will occur, then=
 all bets are
> > > > + * off regarding the count, i.e. no checks can be done.
> > > > + *
> > > > + * Sanity check that in all cases, the event doesn't count when it=
's disabled,
> > > > + * and that KVM correctly emulates the write of an arbitrary value=
.
> > > > + */
> > > > +static void guest_assert_event_count(uint8_t idx,
> > > > +				     struct kvm_x86_pmu_feature event,
> > > > +				     uint32_t pmc, uint32_t pmc_msr)
> > > > +{
> > > > +	uint64_t count;
> > > > +
> > > > +	count =3D _rdpmc(pmc);
> > > > +	if (!this_pmu_has(event))
> > > > +		goto sanity_checks;
> > > > +
> > > > +	switch (idx) {
> > > > +	case INTEL_ARCH_INSTRUCTIONS_RETIRED_INDEX:
> > > > +		GUEST_ASSERT_EQ(count, NUM_INSNS_RETIRED);
> > > > +		break;
> > > > +	case INTEL_ARCH_BRANCHES_RETIRED_INDEX:
> > > > +		GUEST_ASSERT_EQ(count, NUM_BRANCHES);
> > > > +		break;
> > > > +	case INTEL_ARCH_CPU_CYCLES_INDEX:
> > > > +	case INTEL_ARCH_REFERENCE_CYCLES_INDEX:
> > > Since we already support slots event in below guest_test_arch_event()=
, we
> > > can add check for INTEL_ARCH_TOPDOWN_SLOTS_INDEX here.
> > Can that actually be tested at this point, since KVM doesn't support
> > X86_PMU_FEATURE_TOPDOWN_SLOTS, i.e. this_pmu_has() above should always =
fail, no?
>=20
> I suppose X86_PMU_FEATURE_TOPDOWN_SLOTS has been supported in KVM.=C2=A0 =
The
> following output comes from a guest with latest kvm-x86 code on the Sapph=
ire
> Rapids platform.
>=20
> sudo cpuid -l 0xa
> CPU 0:
> =C2=A0=C2=A0 Architecture Performance Monitoring Features (0xa):
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 version ID=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=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=
 =3D 0x2 (2)
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 number of counters per logical processor =
=3D 0x8 (8)
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 bit width of counter=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=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 =3D 0x30 (48)
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 length of EBX bit vector=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=
=A0 =3D 0x8 (8)
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 core cycle event=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=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D available
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 instruction retired event=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=
 =3D available
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 reference cycles event=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=
=A0=C2=A0=C2=A0 =3D available
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 last-level cache ref event=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 =3D a=
vailable
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 last-level cache miss event=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 =3D availab=
le
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 branch inst retired event=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=
 =3D available
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 branch mispred retired event=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D available
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 top-down slots event=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=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 =3D available
>=20
> Current KVM doesn't support fixed counter 3 and pseudo slots event yet, b=
ut
> the architectural slots event is supported and can be programed on a GP
> counter. Current test code can cover this case, so I think we'd better ad=
d
> the check for the slots count.

Can you submit a patch on top, with a changelog that includes justification=
 that
that explains exactly what assertions can be made on the top-down slots eve=
nt
given the "workload" being measured?  I'm definitely not opposed to adding =
coverage
for top-down slots, but at this point, I don't want to respin this series, =
nor do
I want to make that change when applying on the fly.