REQUEST: Syncing tools/arch/arm64/include/asm/cputype.h with the kernel sources

Hi,

Can someone please address this perf build warning:

make: Entering directory '/home/acme/git/perf-tools/tools/perf'
BUILD: Doing 'make -j32' parallel build
Warning: Kernel ABI header differences:
diff -u tools/arch/arm64/include/asm/cputype.h arch/arm64/include/asm/cputype.h

I tried updating that header and got the problems below.

I just merged perf-tools with upstream, will push to tmp.perf-tools at:

https://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools.git tmp.perf-tools

Thanks in advance,

- Arnaldo

⬢ [acme@toolbx perf-tools]$ git diff

tools/arch/arm64/include/asm/cputype.h +10 -13

index 9b73c1aa3ad747ec..08860d482e60009f 100644
@@ -255,6 +255,16 @@
 
 #define read_cpuid(reg)                        read_sysreg_s(SYS_ ## reg)
 
+/*
+ * The CPU ID never changes at run time, so we might as well tell the
+ * compiler that it's constant.  Use this function to read the CPU ID
+ * rather than directly reading processor_id or read_cpuid() directly.
+ */
+static inline u32 __attribute_const__ read_cpuid_id(void)
+{
+       return read_cpuid(MIDR_EL1);
+}
+
 /*
  * Represent a range of MIDR values for a given CPU model and a
  * range of variant/revision values.

@@ -290,31 +300,6 @@ static inline bool midr_is_cpu_model_range(u32 midr, u32 model, u32 rv_min,
        return _model == model && rv >= rv_min && rv <= rv_max;
 }
 
-static inline bool is_midr_in_range(u32 midr, struct midr_range const *range)
-{
-       return midr_is_cpu_model_range(midr, range->model,
-                                      range->rv_min, range->rv_max);
-}
-
-static inline bool
-is_midr_in_range_list(u32 midr, struct midr_range const *ranges)
-{
-       while (ranges->model)
-               if (is_midr_in_range(midr, ranges++))
-                       return true;
-       return false;

⬢ [acme@toolbx perf-tools]$ m
make: Entering directory '/home/acme/git/perf-tools/tools/perf'
BUILD: Doing 'make -j32' parallel build
Warning: Kernel ABI header differences:
diff -u tools/arch/x86/include/asm/msr-index.h arch/x86/include/asm/msr-index.h diff -u tools/arch/x86/include/uapi/asm/svm.h arch/x86/include/uapi/asm/svm.h

Auto-detecting system features:

...                                   libdw: [ on  ]
...                                   glibc: [ on  ]
...                                  libelf: [ on  ]
...                                 libnuma: [ on  ]
...                  numa_num_possible_cpus: [ on  ]
...                               libpython: [ on  ]
...                             libcapstone: [ on  ]
...                               llvm-perf: [ on  ]
...                                    zlib: [ on  ]
...                                    lzma: [ on  ]
...                                     bpf: [ on  ]
...                                  libaio: [ on  ]
...                                 libzstd: [ on  ]
...                              libopenssl: [ on  ]
...                                    rust: [ on  ]

INSTALL libsubcmd_headers
INSTALL libapi_headers
INSTALL libperf_headers
INSTALL libsymbol_headers
INSTALL libbpf_headers
CC /tmp/build/perf-tools/util/arm-spe.o
util/arm-spe.c: In function ‘arm_spe__synth_ds’:
util/arm-spe.c:986:43: error: passing argument 1 of ‘is_midr_in_range_list’ makes pointer from integer without a cast [-Wint-conversion]

  986 |                 if (is_midr_in_range_list(midr, data_source_handles[i].midr_ranges)) {
      |                                           ^~~~
      |                                           |
      |                                           u64 {aka long unsigned int}
In file included from util/arm-spe.c:37:
util/../../arch/arm64/include/asm/cputype.h:310:53: note: expected ‘const struct midr_range *’ but argument is of type ‘u64’ {aka ‘long unsigned int’}
  310 | bool is_midr_in_range_list(struct midr_range const *ranges);
      |                            ~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~
util/arm-spe.c:986:21: error: too many arguments to function ‘is_midr_in_range_list’; expected 1, have 2
  986 |                 if (is_midr_in_range_list(midr, data_source_handles[i].midr_ranges)) {
      |                     ^~~~~~~~~~~~~~~~~~~~~       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
util/../../arch/arm64/include/asm/cputype.h:310:6: note: declared here
  310 | bool is_midr_in_range_list(struct midr_range const *ranges);
      |      ^~~~~~~~~~~~~~~~~~~~~

make[4]: *** [/home/acme/git/perf-tools/tools/build/Makefile.build:95: /tmp/build/perf-tools/util/arm-spe.o] Error 1 make[3]: *** [/home/acme/git/perf-tools/tools/build/Makefile.build:158: util] Error 2
make[2]: *** [Makefile.perf:797: /tmp/build/perf-tools/perf-util-in.o] Error 2
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [Makefile.perf:289: sub-make] Error 2
make: *** [Makefile:119: install-bin] Error 2
make: Leaving directory '/home/acme/git/perf-tools/tools/perf'
⬢ [acme@toolbx perf-tools]$

Hi Arnaldo,

[ + Mark ]

Quoted 9 lines · Arnaldo Carvalho de Melo

Hi,

Can someone please address this perf build warning:

make: Entering directory '/home/acme/git/perf-tools/tools/perf'
BUILD: Doing 'make -j32' parallel build
Warning: Kernel ABI header differences:
diff -u tools/arch/arm64/include/asm/cputype.h arch/arm64/include/asm/cputype.h

Quoted 7 lines

I tried updating that header and got the problems below.

I just merged perf-tools with upstream, will push to tmp.perf-tools at:

https://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools.git tmp.perf-tools

Thanks in advance,

Sorry that this issue has come up again.

A quick summary:

The plan was to extract the CPU ID definitions from cputype.h so that kernel and userspace can share the same definitions. This would avoid keep syncing cputype.h between the kernel and userspace [1].

James worked on this a bit, and later Mark wanted to try a different implementation. However, we haven't posted formal patches yet.

To avoid extra burden on perf maintainers, I suggest removing the cputype.h check in check-headers.sh. In the short term, Arm developers will take responsibility for keeping it up to date. In the long term, once the CPU ID refactoring is completed, we can do a proper cleanup of cputype.h.

James, Mark, is this reasonable?

[1] https://lore.kernel.org/linux-perf-users/aFJ8bQh_30JMzF_-@J2N7QTR9R3/

Are you happy to spin a patch to remove the check?