]> git.itanic.dy.fi Git - linux-stable/commitdiff
tools headers: Update tools's copy of arm64/asm headers
authorNamhyung Kim <namhyung@kernel.org>
Tue, 21 Nov 2023 22:56:44 +0000 (14:56 -0800)
committerNamhyung Kim <namhyung@kernel.org>
Wed, 22 Nov 2023 18:57:47 +0000 (10:57 -0800)
tldr; Just FYI, I'm carrying this on the perf tools tree.

Full explanation:

There used to be no copies, with tools/ code using kernel headers
directly. From time to time tools/perf/ broke due to legitimate kernel
hacking. At some point Linus complained about such direct usage. Then we
adopted the current model.

The way these headers are used in perf are not restricted to just
including them to compile something.

There are sometimes used in scripts that convert defines into string
tables, etc, so some change may break one of these scripts, or new MSRs
may use some different #define pattern, etc.

E.g.:

  $ ls -1 tools/perf/trace/beauty/*.sh | head -5
  tools/perf/trace/beauty/arch_errno_names.sh
  tools/perf/trace/beauty/drm_ioctl.sh
  tools/perf/trace/beauty/fadvise.sh
  tools/perf/trace/beauty/fsconfig.sh
  tools/perf/trace/beauty/fsmount.sh
  $
  $ tools/perf/trace/beauty/fadvise.sh
  static const char *fadvise_advices[] = {
        [0] = "NORMAL",
        [1] = "RANDOM",
        [2] = "SEQUENTIAL",
        [3] = "WILLNEED",
        [4] = "DONTNEED",
        [5] = "NOREUSE",
  };
  $

The tools/perf/check-headers.sh script, part of the tools/ build
process, points out changes in the original files.

So its important not to touch the copies in tools/ when doing changes in
the original kernel headers, that will be done later, when
check-headers.sh inform about the change to the perf tools hackers.

Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Link: https://lore.kernel.org/r/20231121225650.390246-9-namhyung@kernel.org
tools/arch/arm64/include/asm/cputype.h
tools/arch/arm64/include/uapi/asm/kvm.h
tools/arch/arm64/include/uapi/asm/perf_regs.h

index 5f6f84837a490375c8175626e3fec40057bb56d9..7c7493cb571f97bf98b0b4841aeb756d43990718 100644 (file)
 #define ARM_CPU_PART_CORTEX_A78AE      0xD42
 #define ARM_CPU_PART_CORTEX_X1         0xD44
 #define ARM_CPU_PART_CORTEX_A510       0xD46
+#define ARM_CPU_PART_CORTEX_A520       0xD80
 #define ARM_CPU_PART_CORTEX_A710       0xD47
 #define ARM_CPU_PART_CORTEX_A715       0xD4D
 #define ARM_CPU_PART_CORTEX_X2         0xD48
 #define ARM_CPU_PART_NEOVERSE_N2       0xD49
 #define ARM_CPU_PART_CORTEX_A78C       0xD4B
 
-#define APM_CPU_PART_POTENZA           0x000
+#define APM_CPU_PART_XGENE             0x000
+#define APM_CPU_VAR_POTENZA            0x00
 
 #define CAVIUM_CPU_PART_THUNDERX       0x0A1
 #define CAVIUM_CPU_PART_THUNDERX_81XX  0x0A2
 #define MIDR_CORTEX_A78AE      MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A78AE)
 #define MIDR_CORTEX_X1 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_X1)
 #define MIDR_CORTEX_A510 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A510)
+#define MIDR_CORTEX_A520 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A520)
 #define MIDR_CORTEX_A710 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A710)
 #define MIDR_CORTEX_A715 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A715)
 #define MIDR_CORTEX_X2 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_X2)
index f7ddd73a8c0fa2dabffd2782f674f3b484079875..89d2fc872d9f5e63dce2e2a74dfb422c9e255030 100644 (file)
@@ -505,6 +505,38 @@ struct kvm_smccc_filter {
 #define KVM_HYPERCALL_EXIT_SMC         (1U << 0)
 #define KVM_HYPERCALL_EXIT_16BIT       (1U << 1)
 
+/*
+ * Get feature ID registers userspace writable mask.
+ *
+ * From DDI0487J.a, D19.2.66 ("ID_AA64MMFR2_EL1, AArch64 Memory Model
+ * Feature Register 2"):
+ *
+ * "The Feature ID space is defined as the System register space in
+ * AArch64 with op0==3, op1=={0, 1, 3}, CRn==0, CRm=={0-7},
+ * op2=={0-7}."
+ *
+ * This covers all currently known R/O registers that indicate
+ * anything useful feature wise, including the ID registers.
+ *
+ * If we ever need to introduce a new range, it will be described as
+ * such in the range field.
+ */
+#define KVM_ARM_FEATURE_ID_RANGE_IDX(op0, op1, crn, crm, op2)          \
+       ({                                                              \
+               __u64 __op1 = (op1) & 3;                                \
+               __op1 -= (__op1 == 3);                                  \
+               (__op1 << 6 | ((crm) & 7) << 3 | (op2));                \
+       })
+
+#define KVM_ARM_FEATURE_ID_RANGE       0
+#define KVM_ARM_FEATURE_ID_RANGE_SIZE  (3 * 8 * 8)
+
+struct reg_mask_range {
+       __u64 addr;             /* Pointer to mask array */
+       __u32 range;            /* Requested range */
+       __u32 reserved[13];
+};
+
 #endif
 
 #endif /* __ARM_KVM_H__ */
index fd157f46727e9af774d9dfd5a6cccc6d3d88e32c..86e556429e0eb61bac0c873c68c0ebf28e862c61 100644 (file)
@@ -36,11 +36,13 @@ enum perf_event_arm_regs {
        PERF_REG_ARM64_LR,
        PERF_REG_ARM64_SP,
        PERF_REG_ARM64_PC,
+       PERF_REG_ARM64_MAX,
 
        /* Extended/pseudo registers */
-       PERF_REG_ARM64_VG = 46, // SVE Vector Granule
-
-       PERF_REG_ARM64_MAX = PERF_REG_ARM64_PC + 1,
-       PERF_REG_ARM64_EXTENDED_MAX = PERF_REG_ARM64_VG + 1
+       PERF_REG_ARM64_VG = 46,                         /* SVE Vector Granule */
+       PERF_REG_ARM64_EXTENDED_MAX
 };
+
+#define PERF_REG_EXTENDED_MASK (1ULL << PERF_REG_ARM64_VG)
+
 #endif /* _ASM_ARM64_PERF_REGS_H */