** Description changed: [Impact] ACPI-based arm64 systems, such as the Qualcomm QDF2400 and the Hisilicon D05, do not currently have PMU support. This means that tools like perf are unable to use the built-in hardware event counters. [Test Case] On an ACPI-based arm64 system, run the following commands: sudo perf list pmu sudo perf list hw Without ACPI PMU support, these will be empty. [Regression Risk] The changes are restricted to ARM-specific code, other than an added enum value in linux/cpuhotplug.h. This reduces the non-negligible regression risk to the ARM architecture. - For ACPI-based ARM platforms, regression risk is negligible because they - did not have PMU support previously. The non-perf related code is - restricted to a change in arch/arm64/kernel/smp.c that saves off - pointers to each CPU's MADT GICC tables. The code is populating a static - array - so pretty low risk (no pointer dereferences, etc). + For ACPI-based ARM platforms, regression risk is limited because they + did not have PMU support previously. However, if this code is buggy, + previously working commands that just made use of non-PMU events (e.g. + perf top) might start causing problems. To mitigate this, I did a + perf_fuzzer run on a QDF2400 (ACPI-based) and confirmed it survived + (Note: this included a workaround for LP: #1689855, which will need to + be fixed separately once upstreamed). - The most significant regression risk is to ARM non-ACPI platforms. To - mitigate this, we should test this backport on Cavium ThunderX and HP - m400 systems. + For non-ACPI-based (i.e. devicetree) ARM platforms, there is a chance + that the changes have broken PMU support. To mitigate that, I also did a + perf_fuzzer run on a Cavium ThunderX system booted in DT mode, which it + survived. + + Finally, the non-perf related changes in this series are restricted to a + change in arch/arm64/kernel/smp.c that saves off pointers to each CPU's + MADT GICC tables. The code is populating a static array with existing + data - so pretty low risk (no pointer dereferences, etc).
-- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1689661 Title: No PMU support for ACPI-based arm64 systems Status in linux package in Ubuntu: In Progress Status in linux source package in Zesty: In Progress Bug description: [Impact] ACPI-based arm64 systems, such as the Qualcomm QDF2400 and the Hisilicon D05, do not currently have PMU support. This means that tools like perf are unable to use the built-in hardware event counters. [Test Case] On an ACPI-based arm64 system, run the following commands: sudo perf list pmu sudo perf list hw Without ACPI PMU support, these will be empty. [Regression Risk] The changes are restricted to ARM-specific code, other than an added enum value in linux/cpuhotplug.h. This reduces the non-negligible regression risk to the ARM architecture. For ACPI-based ARM platforms, regression risk is limited because they did not have PMU support previously. However, if this code is buggy, previously working commands that just made use of non-PMU events (e.g. perf top) might start causing problems. To mitigate this, I did a perf_fuzzer run on a QDF2400 (ACPI-based) and confirmed it survived (Note: this included a workaround for LP: #1689855, which will need to be fixed separately once upstreamed). For non-ACPI-based (i.e. devicetree) ARM platforms, there is a chance that the changes have broken PMU support. To mitigate that, I also did a perf_fuzzer run on a Cavium ThunderX system booted in DT mode, which it survived. Finally, the non-perf related changes in this series are restricted to a change in arch/arm64/kernel/smp.c that saves off pointers to each CPU's MADT GICC tables. The code is populating a static array with existing data - so pretty low risk (no pointer dereferences, etc). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1689661/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
