On 6/10/26 17:03, Thomas Huth wrote:

On 10/06/2026 11.27, Chinmay Rath wrote:

quoted

On 6/8/26 19:27, Thomas Huth wrote:

quoted

On 08/06/2026 14.45, Thomas Huth wrote:

quoted

On 02/06/2026 08.48, Chinmay Rath wrote:

quoted

From: Nicholas Piggin <npiggin@gmail.com>

Add some initial PMU testing.

- PMC5/6 tests
- PMAE / PMI test
- BHRB basic tests

Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Chinmay Rath <redacted>
---
  lib/powerpc/asm/processor.h |   2 +
  lib/powerpc/asm/reg.h       |   9 +
  lib/powerpc/asm/setup.h     |   1 +
  lib/powerpc/setup.c         |  20 ++
  powerpc/Makefile.common     |   3 +-
  powerpc/pmu.c               | 567 
++++++++++++++++++++++++++++++++++++
  powerpc/unittests.cfg       |   3 +
  7 files changed, 604 insertions(+), 1 deletion(-)
  create mode 100644 powerpc/pmu.c

  Hi Chinmay,

the problem with Clang on Travis [*] still seems to persist:

  https://app.travis-ci.com/github/huth/kvm-unit-tests/jobs/639614142

Could you please have a look?

  Thanks,
   Thomas


[*] This already happened with Nicolas' last version:

  https://www.spinics.net/lists/kvm/msg351218.html

I managed to get access to a ppc64 machine. The error is:

/tmp/pmu-eab466.s: Assembler messages:
/tmp/pmu-eab466.s:1649: Error: unrecognized opcode: `ldat'
clang: error: assembler command failed with exit code 1 (use -v to 
see invocation)
make: *** [<builtin>: powerpc/pmu.o] Error 1

 HTH,
  Thomas

Hi Thomas,

Thanks for looking into this and providing the exact error message.

I was looking into this Travis CI job that you pointed to and noticed 
that the clang version being used was 14.
I was wondering, would it be possible to use a newer version of clang 
for the job since LDAT is a legit PPC insn,
that was introduced with Power 9, ISA version 3.0, way back a decade 
in 2016 !
So I was wondering if using a newer version of clang that recognizes 
the instruction would be a better approach.

I can reproduce the very same issue on a ppc64le box with Clang 22:

# clang --version
clang version 22.1.6 (Fedora 22.1.6-1.fc44)
Target: ppc64le-redhat-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Configuration file: /etc/clang/ppc64le-redhat-linux-gnu-clang.cfg
# make
clang -no-integrated-as -std=gnu99 -ffreestanding -O2 -msoft-float 
-mno-altivec  -I /root/kvm-unit-tests/lib -I 
/root/kvm-unit-tests/lib/libfdt -I lib -Wa,-mregnames -g -MMD -MP -MF 
powerpc/.pmu.d -fno-strict-aliasing -fno-common -Wall -Wwrite-strings 
-Wempty-body -Wuninitialized -Wignored-qualifiers -Wno-missing-braces 
-Werror  -fomit-frame-pointer -fno-stack-protector    
-Wno-frame-address   -fno-pic -Wunused-but-set-parameter  
-Wno-override-init -Wmissing-prototypes -Wstrict-prototypes  
-mlittle-endian   -c -o powerpc/pmu.o powerpc/pmu.c
/tmp/pmu-f0c247.s: Assembler messages:
/tmp/pmu-f0c247.s:1656: Error: unrecognized opcode: `ldat'
clang: error: assembler command failed with exit code 1 (use -v to see 
invocation)
make: *** [<builtin>: powerpc/pmu.o] Error 1

Does compiling with Clang work for you? If so, which version?

 Thomas

Thanks for sharing this observation Thomas. I did some digging on a 
ppc64 machine and found the following :

The problem isn't with clang. Clang is able to perfectly identify LDAT 
insn. This can be verified by writing a small C program using LDAT 
within a similar asm volatile block and compiling with Clang. Sails smooth.
The problem is, the GNU assembler does not identify LDAT, unless 
"-mpower10" flag is passed to it. Can be verified by writing a small .S 
program making use of LDAT and passing to 'as', the GNU assembler binary.
In your Travis CI log, as I can check, the following config is used :
$ export CONFIG="--arch=ppc64 --endian=little --cc=clang 
--cflags=-no-integrated-as"
"no-integrated-as" defers the assembling job to GNU assembler, and since 
no "-mpower10" flag is passed, the compilation fails.
Using the following flag in the config instead, passes -mpower10 to GNU 
assembler and gets the compilation job done : 
  --cflags="-no-integrated-as -Wa,-mpower10"

Thanks,
Chinmay

PS: I will be away traveling for a while, will get back to this as soon 
as I am back. Thanks for understanding   :)