• State Not Answered
  • Locked Locked
  • Replies 1 reply
  • Subscribers 10 subscribers
  • Views 2460 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Enable SPE(Statistical Profiling Extension)causes higher exception level problems

Zack Tsai

I tried using the method and referring document by arm Official documents,but an exception appears in the kernel log

​checked for the path without "/sys/bus/event_source/devices/arm_spe_XX."

 The hardware is arm-cortex x3

​ Exception Message from above link:

> [  0.774345] swapper/0: arm_spe_pmu spe-x3: [name:arm_spe_pmu&]profiling buffer owned by higher exception level

​

I don't know what causes this exception,

I've confirmed some things

  1. my kernel Version is 5.15 <---- at NS-EL1
  2. SPE driver is Linux source code ,but a few patch  not catch up I'm not sure whether that's the reason why the SPE won't enable arm_spe_pmu.c - drivers/perf/arm_spe_pmu.c - Linux source code (v5.15.87) - Bootlin
  3. mdcr_el3 = 0.8930000 NSPB, bits [13:12] is 0b11

    bits[13:12] is ob11 and its meaning is as follows

    Profiling Buffer uses Non-secure Virtual Addresses. Statistical Profiling enabled in Non-secure state and disabled in Secure state. Accesses to Statistical Profiling and Profiling Buffer control registers at EL2 and EL1 in Secure state generate Trap exceptions to EL3.

  4. PMBLIMITR_EL1 = 0x1 pmbsr = 0xfe0d003f

Please provide me with more Information ?

Parents
  • 0

    Please check if the target system you are working on supports Statistical Profiling Extension(SPE). This is reflected in the register ID_AA64DFR0_EL1, PMSVer, bits [35:32]:

    https://developer.arm.com/documentation/ddi0595/2021-03/AArch64-Registers/ID-AA64DFR0-EL1--AArch64-Debug-Feature-Register-0

    Please check and ensure the target system setup for enabling SPE is correct: 
    https://developer.arm.com/documentation/101814/0801/Target-Setup/System-requirements-for-SPE-support

    Ensure the latest Linux kernel and latest SPE driver with all relevant patches are applied (Patches if any/all applicable depending upon the Linux version you are using) 

    The error message,

    "profiling buffer is owned by a higher exception level"

    is observed when PMBIDR_EL1 register read from the driver code reflects that the P-bit is set to 1.

    From the driver code, https://github.com/torvalds/linux/blob/master/drivers/perf/arm_spe_pmu.c

    /* Read PMBIDR first to determine whether or not we have access */
    reg = read_sysreg_s(SYS_PMBIDR_EL1);
    if (reg & BIT(SYS_PMBIDR_EL1_P_SHIFT)) {
    dev_err(dev,
    "profiling buffer owned by higher exception level\n");
    return;
    }

    "

    As per the PMBIDR register details (please refer to details when P-bit is read as one, copied below for quick reference): https://developer.arm.com/documentation/ddi0601/2020-12/AArch64-Registers/PMBIDR-EL1--Profiling-Buffer-ID-Register

     +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

    P, bit [4]

    Programming not allowed. The Profiling Buffer is owned by a higher Exception level or the other Security state.

    P Meaning
    0b0

    Profiling Buffer is owned by the current or a lower Exception level in the current Security state.
    0b1

    Profiling Buffer is owned by a higher Exception level or the other Security state.

    The value read from this field depends on the current Exception level and the Effective values of MDCR_EL3.NSPB and MDCR_EL2.E2PB:

    • If EL3 is implemented, and either MDCR_EL3.NSPB == 0b00 or MDCR_EL3.NSPB == 0b01, this bit reads as one from:
      • Non-secure EL1.
      • Non-secure EL2.
      • If Secure EL2 is implemented and enabled, and MDCR_EL2.E2PB == 0b00, Secure EL1.
    • If EL3 is implemented, and either MDCR_EL3.NSPB == 0b10 or MDCR_EL3.NSPB == 0b11, this bit reads as one from:
      • Secure EL1.
      • If Secure EL2 is implemented, Secure EL2.
      • If EL2 is implemented and MDCR_EL2.E2PB == 0b00, Non-secure EL1.
    • If EL3 is not implemented, EL2 is implemented, and MDCR_EL2.E2PB == 0b00, this bit reads as one from EL1.
    • Otherwise, this bit reads as zero.

    +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

    Please check when PMBIDR_EL1 is read by the SPE driver code, what are the values observed in MDCR_EL2 and MDCR_EL3 registers. 
    When in non-secure EL1, if MDCR_EL3.    NSPB bits [13:12] = 0b11, and MDCR_EL2.E2PB, bits [13:12] = 0b11, PMBIDR_EL1.P should read 0 and you should not observe the error message "profiling buffer is owned by a higher exception level".

    Note that, if you are booting the Linux Kernel at EL1 directly it should work. However, not as a Virtual machine. The KVM does not support SPE for a guest OS. In this case you might see the error message "profiling buffer is owned by a higher exception level" as the guest OS will read PMBIDR.P bit as one.

Reply
  • 0

    Please check if the target system you are working on supports Statistical Profiling Extension(SPE). This is reflected in the register ID_AA64DFR0_EL1, PMSVer, bits [35:32]:

    https://developer.arm.com/documentation/ddi0595/2021-03/AArch64-Registers/ID-AA64DFR0-EL1--AArch64-Debug-Feature-Register-0

    Please check and ensure the target system setup for enabling SPE is correct: 
    https://developer.arm.com/documentation/101814/0801/Target-Setup/System-requirements-for-SPE-support

    Ensure the latest Linux kernel and latest SPE driver with all relevant patches are applied (Patches if any/all applicable depending upon the Linux version you are using) 

    The error message,

    "profiling buffer is owned by a higher exception level"

    is observed when PMBIDR_EL1 register read from the driver code reflects that the P-bit is set to 1.

    From the driver code, https://github.com/torvalds/linux/blob/master/drivers/perf/arm_spe_pmu.c

    /* Read PMBIDR first to determine whether or not we have access */
    reg = read_sysreg_s(SYS_PMBIDR_EL1);
    if (reg & BIT(SYS_PMBIDR_EL1_P_SHIFT)) {
    dev_err(dev,
    "profiling buffer owned by higher exception level\n");
    return;
    }

    "

    As per the PMBIDR register details (please refer to details when P-bit is read as one, copied below for quick reference): https://developer.arm.com/documentation/ddi0601/2020-12/AArch64-Registers/PMBIDR-EL1--Profiling-Buffer-ID-Register

     +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

    P, bit [4]

    Programming not allowed. The Profiling Buffer is owned by a higher Exception level or the other Security state.

    P Meaning
    0b0

    Profiling Buffer is owned by the current or a lower Exception level in the current Security state.
    0b1

    Profiling Buffer is owned by a higher Exception level or the other Security state.

    The value read from this field depends on the current Exception level and the Effective values of MDCR_EL3.NSPB and MDCR_EL2.E2PB:

    • If EL3 is implemented, and either MDCR_EL3.NSPB == 0b00 or MDCR_EL3.NSPB == 0b01, this bit reads as one from:
      • Non-secure EL1.
      • Non-secure EL2.
      • If Secure EL2 is implemented and enabled, and MDCR_EL2.E2PB == 0b00, Secure EL1.
    • If EL3 is implemented, and either MDCR_EL3.NSPB == 0b10 or MDCR_EL3.NSPB == 0b11, this bit reads as one from:
      • Secure EL1.
      • If Secure EL2 is implemented, Secure EL2.
      • If EL2 is implemented and MDCR_EL2.E2PB == 0b00, Non-secure EL1.
    • If EL3 is not implemented, EL2 is implemented, and MDCR_EL2.E2PB == 0b00, this bit reads as one from EL1.
    • Otherwise, this bit reads as zero.

    +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

    Please check when PMBIDR_EL1 is read by the SPE driver code, what are the values observed in MDCR_EL2 and MDCR_EL3 registers. 
    When in non-secure EL1, if MDCR_EL3.    NSPB bits [13:12] = 0b11, and MDCR_EL2.E2PB, bits [13:12] = 0b11, PMBIDR_EL1.P should read 0 and you should not observe the error message "profiling buffer is owned by a higher exception level".

    Note that, if you are booting the Linux Kernel at EL1 directly it should work. However, not as a Virtual machine. The KVM does not support SPE for a guest OS. In this case you might see the error message "profiling buffer is owned by a higher exception level" as the guest OS will read PMBIDR.P bit as one.

Children
No data