[0/6] Extend pmu_counters_test to AMD CPUs

Message

Colton Lewis Aug. 13, 2024, 4:42 p.m. UTC

(I was positive I had sent this already, but I couldn't find it on the
mailing list to reply to and ask for reviews.)

Extend pmu_counters_test to AMD CPUs.

As the AMD PMU is quite different from Intel with different events and
feature sets, this series introduces a new code path to test it,
specifically focusing on the core counters including the
PerfCtrExtCore and PerfMonV2 features. Northbridge counters and cache
counters exist, but are not as important and can be deferred to a
later series.

The first patch is a bug fix that could be submitted separately.

The series has been tested on both Intel and AMD machines, but I have
not found an AMD machine old enough to lack PerfCtrExtCore. I have
made efforts that no part of the code has any dependency on its
presence.

I am aware of similar work in this direction done by Jinrong Liang
[1]. He told me he is not working on it currently and I am not
intruding by making my own submission.

[1] https://lore.kernel.org/kvm/[e-mail]/

Colton Lewis (6):
  KVM: x86: selftests: Fix typos in macro variable use
  KVM: x86: selftests: Define AMD PMU CPUID leaves
  KVM: x86: selftests: Set up AMD VM in pmu_counters_test
  KVM: x86: selftests: Test read/write core counters
  KVM: x86: selftests: Test core events
  KVM: x86: selftests: Test PerfMonV2

 .../selftests/kvm/include/x86_64/processor.h  |   7 +
 .../selftests/kvm/x86_64/pmu_counters_test.c  | 267 ++++++++++++++++--
 2 files changed, 249 insertions(+), 25 deletions(-)

--
2.46.0.76.ge559c4bf1a-goog

Comments

Sean Christopherson Aug. 13, 2024, 5:36 p.m. UTC | #1

On Tue, Aug 13, 2024, Colton Lewis wrote:
> (I was positive I had sent this already, but I couldn't find it on the
> mailing list to reply to and ask for reviews.)

You did[*], it's sitting in my todo folder.  Two things.

1. Err on the side of caution when potentially resending, and tag everything
RESEND.  Someone seeing a RESEND version without having seen the original version
is no big deal.  But someone seeing two copies of the same patches/emails can get
quite confusing.

2. Something is funky in your send flow.  The original posing says 0/7 in the
cover letter, but there are only 6 patches.

[*] https://lore.kernel.org/all/[e-mail]

Sean Christopherson Aug. 14, 2024, 1:03 a.m. UTC | #2

On Tue, Aug 13, 2024, Colton Lewis wrote:
> Sean Christopherson <[e-mail]> writes:
> 
> > On Tue, Aug 13, 2024, Colton Lewis wrote:
> > > (I was positive I had sent this already, but I couldn't find it on the
> > > mailing list to reply to and ask for reviews.)
> 
> > You did[*], it's sitting in my todo folder.  Two things.
> 
> > 1. Err on the side of caution when potentially resending, and tag
> > everything
> > RESEND.  Someone seeing a RESEND version without having seen the
> > original version
> > is no big deal.  But someone seeing two copies of the same
> > patches/emails can get
> > quite confusing.
> 
> Sorry for jumping the gun. I couldn't find the original patches in my
> email or on the (wrong) list and panicked.

Ha, no worries.  FWIW, I highly recommend using lore if you can't (quickly) find
something in your own mailbox.  If it hit a tracked list, lore will have it.  And
if you use our corporate mail, the retention policy is 18 months unless you go
out of your way to tag mails to be kept, i.e. lore is more trustworthy in the
long run.

https://lore.kernel.org/all/?q=f:[e-mail]