On 6/10/26 17:03, Thomas Huth wrote:
On 10/06/2026 11.27, Chinmay Rath wrote:

On 6/8/26 19:27, Thomas Huth wrote:
On 08/06/2026 14.45, Thomas Huth wrote:
On 02/06/2026 08.48, Chinmay Rath wrote:
From: Nicholas Piggin <[email protected]>

Add some initial PMU testing.

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

Signed-off-by: Nicholas Piggin <[email protected]>
Signed-off-by: Chinmay Rath <[email protected]>
---
  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   :)


Reply via email to