arm_pmu: ACPI support

Currently the ACPI parking protocol code needs to parse each CPU's MADT GICC table to extract the mailbox address and so on. Each time we parse a GICC table, we call back to the parking protocol code to parse it.

This has been fine so far, but we're about to have more code that needs to extract data from the GICC tables, and adding a callback for each user is going to get unwieldy.

Instead, this patch ensures that we stash a copy of each CPU's GICC table at boot time, such that anything needing to parse it can later request it. This will allow for other parsers of GICC, and for simplification to the ACPI parking protocol code. Note that we must store a copy, rather than a pointer, since the core ACPI code temporarily maps/unmaps tables while iterating over them.

Since we parse the MADT before we know how many CPUs we have (and hence before we setup the percpu areas), we must use an NR_CPUS sized array.

Signed-off-by Mark Rutland <[email protected]>

Cc Catalin Marinas <[email protected]>

Cc Lorenzo Pieralisi <[email protected]>

Cc Will Deacon <[email protected]>

---
 arch/arm64/include/asm/acpi.h |  2 ++
 arch/arm64/kernel/smp.c       | 10 ++++++++++
 2 files changed, 12 insertions(+)

arch/arm64/include/asm/acpi.h +2 -0

index c1976c0..0e99978 100644
@@ -85,6 +85,8 @@ static inline bool acpi_has_cpu_in_madt(void)
 	return true;
 }
 
+struct acpi_madt_generic_interrupt *acpi_cpu_get_madt_gicc(int cpu);
+
 static inline void arch_fix_phys_package_id(int num, u32 slot) { }
 void __init acpi_init_cpus(void);
 

arch/arm64/kernel/smp.c +10 -0

index ef1caae..390c277 100644
@@ -518,6 +518,13 @@ static int __init smp_cpu_setup(int cpu)
 static unsigned int cpu_count = 1;
 
 #ifdef CONFIG_ACPI
+static struct acpi_madt_generic_interrupt cpu_madt_gicc[NR_CPUS];
+
+struct acpi_madt_generic_interrupt *acpi_cpu_get_madt_gicc(int cpu)
+{
+	return &cpu_madt_gicc[cpu];
+}
+
 /*
  * acpi_map_gic_cpu_interface - parse processor MADT entry
  *

@@ -552,6 +559,7 @@ static int __init smp_cpu_setup(int cpu)
 			return;
 		}
 		bootcpu_valid = true;
+		cpu_madt_gicc[0] = *processor;
 		early_map_cpu_to_node(0, acpi_numa_get_nid(0, hwid));
 		return;
 	}

@@ -562,6 +570,8 @@ static int __init smp_cpu_setup(int cpu)
 	/* map the logical cpu id to cpu MPIDR */
 	cpu_logical_map(cpu_count) = hwid;
 
+	cpu_madt_gicc[cpu_count] = *processor;
+
 	/*
 	 * Set-up the ACPI parking protocol cpu entries
 	 * while initializing the cpu_logical_map to

Signature · 1 line

1.9.1

Now that we have acpi_cpu_get_madt_gicc(), we can use values from the MADT GICC table directly, and no longer need to stash a copy in our own datastructure.

This allows us to kill off the acpi_set_mailbox_entry() callback, too.

Signed-off-by Mark Rutland <[email protected]>

Cc Catalin Marinas <[email protected]>

Cc Lorenzo Pieralisi <[email protected]>

Cc Will Deacon <[email protected]>

---
 arch/arm64/include/asm/acpi.h             |  5 ----
 arch/arm64/kernel/acpi_parking_protocol.c | 38 +++++++++----------------------
 arch/arm64/kernel/smp.c                   | 11 ---------
 3 files changed, 11 insertions(+), 43 deletions(-)

arch/arm64/include/asm/acpi.h +0 -5

index 0e99978..ebf88e3 100644
@@ -96,13 +96,8 @@ static inline void acpi_init_cpus(void) { }
 
 #ifdef CONFIG_ARM64_ACPI_PARKING_PROTOCOL
 bool acpi_parking_protocol_valid(int cpu);
-void __init
-acpi_set_mailbox_entry(int cpu, struct acpi_madt_generic_interrupt *processor);
 #else
 static inline bool acpi_parking_protocol_valid(int cpu) { return false; }
-static inline void
-acpi_set_mailbox_entry(int cpu, struct acpi_madt_generic_interrupt *processor)
-{}
 #endif
 
 static inline const char *acpi_get_enable_method(int cpu)

arch/arm64/kernel/acpi_parking_protocol.c +0 -9

index 1f5655c..700a83a 100644
@@ -28,36 +28,21 @@ struct parking_protocol_mailbox {
 	__le64 entry_point;
 };
 
-struct cpu_mailbox_entry {
-	struct parking_protocol_mailbox __iomem *mailbox;
-	phys_addr_t mailbox_addr;
-	u8 version;
-	u8 gic_cpu_id;
-};
-
-static struct cpu_mailbox_entry cpu_mailbox_entries[NR_CPUS];
-

arch/arm64/kernel/acpi_parking_protocol.c +10 -9

 bool acpi_parking_protocol_valid(int cpu)
 {
-	struct cpu_mailbox_entry *cpu_entry = &cpu_mailbox_entries[cpu];
+	struct acpi_madt_generic_interrupt *p = acpi_cpu_get_madt_gicc(cpu);
 
-	return cpu_entry->mailbox_addr && cpu_entry->version;
+	return p->parked_address && p->parking_version;
 }
 
 static int acpi_parking_protocol_cpu_init(unsigned int cpu)
 {
+	struct acpi_madt_generic_interrupt *p = acpi_cpu_get_madt_gicc(cpu);
+
 	pr_debug("%s: ACPI parked addr=%llx\n", __func__,
-		  cpu_mailbox_entries[cpu].mailbox_addr);
+		 p->parked_address);
 
 	return 0;
 }

@@ -69,7 +54,7 @@ static int acpi_parking_protocol_cpu_prepare(unsigned int cpu)
 
 static int acpi_parking_protocol_cpu_boot(unsigned int cpu)
 {
-	struct cpu_mailbox_entry *cpu_entry = &cpu_mailbox_entries[cpu];
+	struct acpi_madt_generic_interrupt *p = acpi_cpu_get_madt_gicc(cpu);
 	struct parking_protocol_mailbox __iomem *mailbox;
 	__le32 cpu_id;
 

@@ -84,7 +69,7 @@ static int acpi_parking_protocol_cpu_boot(unsigned int cpu)
 	 * by the kernel (it clashes with the linear mapping attributes
 	 * specifications).
 	 */
-	mailbox = ioremap(cpu_entry->mailbox_addr, sizeof(*mailbox));
+	mailbox = ioremap(p->parked_address, sizeof(*mailbox));
 	if (!mailbox)
 		return -EIO;
 

@@ -102,7 +87,7 @@ static int acpi_parking_protocol_cpu_boot(unsigned int cpu)
 	 * stash the mailbox address mapping to use it for further FW
 	 * checks in the postboot method
 	 */
-	cpu_entry->mailbox = mailbox;
+	mailboxes[cpu] = mailbox;
 
 	/*
 	 * We write the entry point and cpu id as LE regardless of the

@@ -111,7 +96,7 @@ static int acpi_parking_protocol_cpu_boot(unsigned int cpu)
 	 * Boot-Loader's endianness before jumping.
 	 */
 	writeq_relaxed(__pa_symbol(secondary_entry), &mailbox->entry_point);
-	writel_relaxed(cpu_entry->gic_cpu_id, &mailbox->cpu_id);
+	writel_relaxed(p->cpu_interface_number, &mailbox->cpu_id);
 
 	arch_send_wakeup_ipi_mask(cpumask_of(cpu));
 

@@ -121,8 +106,7 @@ static int acpi_parking_protocol_cpu_boot(unsigned int cpu)
 static void acpi_parking_protocol_cpu_postboot(void)
 {
 	int cpu = smp_processor_id();
-	struct cpu_mailbox_entry *cpu_entry = &cpu_mailbox_entries[cpu];
-	struct parking_protocol_mailbox __iomem *mailbox = cpu_entry->mailbox;
+	struct parking_protocol_mailbox __iomem *mailbox = mailboxes[cpu];
 	__le64 entry_point;
 
 	entry_point = readl_relaxed(&mailbox->entry_point);

arch/arm64/kernel/smp.c +0 -11

index 390c277..b37dd83 100644
@@ -572,17 +572,6 @@ struct acpi_madt_generic_interrupt *acpi_cpu_get_madt_gicc(int cpu)
 
 	cpu_madt_gicc[cpu_count] = *processor;
 
-	/*
-	 * Set-up the ACPI parking protocol cpu entries
-	 * while initializing the cpu_logical_map to
-	 * avoid parsing MADT entries multiple times for
-	 * nothing (ie a valid cpu_logical_map entry should
-	 * contain a valid parking protocol data set to
-	 * initialize the cpu if the parking protocol is
-	 * the only available enable method).
-	 */
-	acpi_set_mailbox_entry(cpu_count, processor);
-
 	early_map_cpu_to_node(cpu_count, acpi_numa_get_nid(cpu_count, hwid));
 
 	cpu_count++;

Signature · 1 line

1.9.1

Quoted 1 line · Mark Rutland

+static struct parking_protocol_mailbox __iomem *mailboxes[NR_CPUS];

Nit: If I am not mistaken it can be made a percpu pointer.

Other than that:

Reviewed-by Lorenzo Pieralisi <[email protected]>

Quoted 5 lines · Lorenzo Pieralisi

Quoted 1 line · Mark Rutland

+static struct parking_protocol_mailbox __iomem *mailboxes[NR_CPUS];

Nit: If I am not mistaken it can be made a percpu pointer.

Unfortunately, we don't set up the percpu areas until we know how many CPUs are possible (i.e. after we've parsed the MADT).

The flow looks like:

start_kernel()
setup_arch()
smp_init_cpus()
acpi_table_parse_madt()
acpi_parse_gic_cpu_interface()
acpi_map_gic_cpu_interface() // setup cpu mailbox here

...
setup_per_cpu_areas() // percpu available here

Otherwise, I completely agree that a percpu pointer would be the right thing to do.

Quoted 4 lines

Other than that:

Reviewed-by Lorenzo Pieralisi <[email protected]>

I take it this stands, given the above?

Quoted 10 lines · Mark Rutland

Quoted 5 lines · Lorenzo Pieralisi

Quoted 1 line · Mark Rutland

+static struct parking_protocol_mailbox __iomem *mailboxes[NR_CPUS];

Nit: If I am not mistaken it can be made a percpu pointer.

Unfortunately, we don't set up the percpu areas until we know how many CPUs are possible (i.e. after we've parsed the MADT).

Quoted 8 lines

The flow looks like:

start_kernel()
setup_arch()
smp_init_cpus()
acpi_table_parse_madt()
acpi_parse_gic_cpu_interface()
acpi_map_gic_cpu_interface() // setup cpu mailbox here

The mailbox data yes, not the pointer at which it is mapped (which is what gets stashed in mailboxes[]).

Quoted 20 lines · Lorenzo Pieralisi

Quoted 10 lines · Mark Rutland

Quoted 5 lines · Lorenzo Pieralisi

Quoted 1 line · Mark Rutland

+static struct parking_protocol_mailbox __iomem *mailboxes[NR_CPUS];

Nit: If I am not mistaken it can be made a percpu pointer.

Unfortunately, we don't set up the percpu areas until we know how many CPUs are possible (i.e. after we've parsed the MADT).

Quoted 8 lines

The flow looks like:

start_kernel()
setup_arch()
smp_init_cpus()
acpi_table_parse_madt()
acpi_parse_gic_cpu_interface()
acpi_map_gic_cpu_interface() // setup cpu mailbox here

Quoted 2 lines

The mailbox data yes, not the pointer at which it is mapped (which is what gets stashed in mailboxes[]).

Sorry, I got myself confused here between this and the MADT GICC stashing to which the above does apply.

You are correct that this can and should be a percpu pointer.

I'll fix this up. I just need to figure out where the __iomem attribute is supposed to live on a percpu definition.

From 3045f18e798a37b4956f837ed264704500ca45b9 Mon Sep 17 00:00:00 2001

Now that we have a framework to handle the ACPI bits, make the PMUv3 code use this. The framework is a little different to what was originally envisaged, and we can drop some unused support code in the process of moving over to it.

Signed-off-by Mark Rutland <[email protected]>

Cc Jeremy Linton <[email protected]>

Cc Will Deacon <[email protected]>

---
 arch/arm64/kernel/perf_event.c | 26 +++++++++-----------------
 1 file changed, 9 insertions(+), 17 deletions(-)

One thing I'm not sure about here is how to verify that PMUv3 is supported. I can put a test in armv8_pmuv3_init(), but it feels like that should be verified earlier.

Mark.

arch/arm64/kernel/perf_event.c +1 -16

index 57ae9d9..daf95919 100644
@@ -1081,24 +1081,9 @@ static int armv8_vulcan_pmu_init(struct arm_pmu *cpu_pmu)
        {},
 };
 
-/*
- * Non DT systems have their micro/arch events probed at run-time.
- * A fairly complete list of generic events are provided and ones that
- * aren't supported by the current PMU are disabled.
- */
-static const struct pmu_probe_info armv8_pmu_probe_table[] = {
-       PMU_PROBE(0, 0, armv8_pmuv3_init), /* enable all defined counters */
-       { /* sentinel value */ }
-};
-
 static int armv8_pmu_device_probe(struct platform_device *pdev)
 {
-       if (acpi_disabled)
-               return arm_pmu_device_probe(pdev, armv8_pmu_of_device_ids,
-                                           NULL);
-
-       return arm_pmu_device_probe(pdev, armv8_pmu_of_device_ids,
-                                   armv8_pmu_probe_table);
+       return arm_pmu_device_probe(pdev, armv8_pmu_of_device_ids, NULL);
 }
 
 static struct platform_driver armv8_pmu_driver = {

arch/arm64/kernel/perf_event.c +2 -1

+}
+device_initcall(armv8_pmu_driver_init)
--

1.9.1

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

arch/arm64/kernel/perf_event.c static int armv8_pmu_device_probe(struct platform_device *pdev) · line 1102

Quoted 6 lines

arch/arm64/kernel/perf_event.c +6 -0

+int __init armv8_pmu_driver_init(void)
+{
+       if (acpi_disabled)
+               return platform_driver_register(&armv8_pmu_driver);
+       else
+               return arm_pmu_acpi_probe(armv8_pmuv3_init);

i think this function needs to be updated to
probe SoC specific init (armv8_a53_pmu_init, armv8_vulcan_pmu_init etc) as well.

Hi Ganapatrao,

Quoted 10 lines · Ganapatrao Kulkarni

arch/arm64/kernel/perf_event.c static int armv8_pmu_device_probe(struct platform_device *pdev) · line 1102

Quoted 6 lines

arch/arm64/kernel/perf_event.c +6 -0

+int __init armv8_pmu_driver_init(void)
+{
+       if (acpi_disabled)
+               return platform_driver_register(&armv8_pmu_driver);
+       else
+               return arm_pmu_acpi_probe(armv8_pmuv3_init);

i think this function needs to be updated to
probe SoC specific init (armv8_a53_pmu_init, armv8_vulcan_pmu_init etc) as well.

Only exposing generic PMUv3 here was a deliberate decision, based on prior discussions, so as to keep things consistent on ACPI platforms regardless of which CPU types the PMU code is immediately aware of.

I should have documented this better; sorry about that.

All events which can be enumerated via the PMU ID registers will be exposed via sysfs.

Hi Ganapatrao,

Quoted 10 lines · Ganapatrao Kulkarni

arch/arm64/kernel/perf_event.c static int armv8_pmu_device_probe(struct platform_device *pdev) · line 1102

Quoted 6 lines

arch/arm64/kernel/perf_event.c +6 -0

+int __init armv8_pmu_driver_init(void)
+{
+       if (acpi_disabled)
+               return platform_driver_register(&armv8_pmu_driver);
+       else
+               return arm_pmu_acpi_probe(armv8_pmuv3_init);

i think this function needs to be updated to
probe SoC specific init (armv8_a53_pmu_init, armv8_vulcan_pmu_init etc) as well.

Only exposing generic PMUv3 here was a deliberate decision, based on prior discussions, so as to keep things consistent on ACPI platforms regardless of which CPU types the PMU code is immediately aware of.

I should have documented this better; sorry about that.

All events which can be enumerated via the PMU ID registers will be exposed via sysfs.

Other events (e.g. those which are implementation defined) will not be exposed via sysfs, but can still be used as raw events.

There's been some perf tool work to allow these to be enumerated in userspace based on JSON files. This allows new events to be supported with a userspace update, event when the kernel itself is older than the CPU in question, and does not know anything about its events.

Thanks,
Mark.

Hi Ganapatrao,

Quoted 9 lines · Ganapatrao Kulkarni

arch/arm64/kernel/perf_event.c static int armv8_pmu_device_probe(struct platform_device *pdev) · line 1102

Quoted 6 lines

arch/arm64/kernel/perf_event.c +6 -0

+int __init armv8_pmu_driver_init(void)
+{
+       if (acpi_disabled)
+               return platform_driver_register(&armv8_pmu_driver);
+       else
+               return arm_pmu_acpi_probe(armv8_pmuv3_init);

i think this function needs to be updated to
probe SoC specific init (armv8_a53_pmu_init, armv8_vulcan_pmu_init etc) as well.

Only exposing generic PMUv3 here was a deliberate decision, based on prior discussions, so as to keep things consistent on ACPI platforms regardless of which CPU types the PMU code is immediately aware of.

I should have documented this better; sorry about that.

All events which can be enumerated via the PMU ID registers will be exposed via sysfs.

Other events (e.g. those which are implementation defined) will not be exposed via sysfs, but can still be used as raw events.

Hi,

This series implements ACPI support in the ARM PMU code. It borrows some code from Jeremy's series [1], but takes a different approach to probing and association, using the usual hotplug state machine, minimising external changes required, and simplifying the relationship with the common arm_pmu code.

The first few patches are preparatory cleanup/refactoring, with the latter half of the series being specific to ACPI support.

The series is based on my IRQ rework patches [2]. I've pushed the whole series out to the arm/perf/acpi branch [3] of my kernel.org repo.

Due to the innards of the hotplug callback framework, it's not entirely safe to register a PMU in a hotplug callback. Due to this, we can only associated hotplugged CPUs with a PMU if a matching CPU was around at probe time. A similar restriction already applies to DT systems. We may be able to relax this with some future work.

I've given this some testing on a Juno platform (using SPIs). To see that IRQs are correctly associated, I've tested with the following:

  $ taskset -c ${SOME_CPU_HERE} perf record \
    -e armv8_pmuv3_0/cpu_cycles/ \
    -e armv8_pmuv3_1/cpu_cycles/ \
    cat /proc/interrupts

I've also booted with nr_cpus temporarily capped (passing maxcpus=) to test the association logic. This has also been tested in a VM using PPIs; I do not have access to a host machine which itself uses PPIs.

Thanks,
Mark.

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2017-January/482397.html
[2] http://lists.infradead.org/pipermail/linux-arm-kernel/2017-March/492891.html
[3] git://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git arm/perf/acpi

Mark Rutland (14):
drivers/perf: arm_pmu: remove pointless PMU disabling drivers/perf: arm_pmu: define armpmu_init_fn drivers/perf: arm_pmu: fold init into alloc drivers/perf: arm_pmu: factor out pmu registration drivers/perf: arm_pmu: simplify cpu_pmu_request_irqs() drivers/perf: arm_pmu: handle no platform_device drivers/perf: arm_pmu: rename irq request/free functions drivers/perf: arm_pmu: split cpu-local irq request/free drivers/perf: arm_pmu: move irq request/free into probe drivers/perf: arm_pmu: split out platform device probe logic
arm64: add function to get a cpu's MADT GICC table
arm64: kill acpi_set_mailbox_entry()
drivers/perf: arm_pmu: add ACPI framework
arm64: pmuv3: use arm_pmu ACPI framework

 arch/arm64/include/asm/acpi.h             |   7 +-
 arch/arm64/kernel/acpi_parking_protocol.c |  38 +--
 arch/arm64/kernel/perf_event.c            |  26 +-
 arch/arm64/kernel/smp.c                   |  19 +-
 drivers/perf/Kconfig                      |   4 +
 drivers/perf/Makefile                     |   3 +-
 drivers/perf/arm_pmu.c                    | 383 ++++++++----------------------
 drivers/perf/arm_pmu_acpi.c               | 237 ++++++++++++++++++
 drivers/perf/arm_pmu_platform.c           | 235 ++++++++++++++++++
 include/linux/cpuhotplug.h                |   1 +
 include/linux/perf/arm_pmu.h              |  22 +-
 11 files changed, 626 insertions(+), 349 deletions(-)
 create mode 100644 drivers/perf/arm_pmu_acpi.c
 create mode 100644 drivers/perf/arm_pmu_platform.c

Quoted 1 line · Mark Rutland

This series implements ACPI support in the ARM PMU code.

I tried these patches on a m400 (which uses PPIs), and the kernel fails to come up enough to login via the network (which works with 4.11rc1 without these patches). So, I suspect there is something wrong with them.

Given that SPCR/etc is also broken and the kernel itself seems to fail if I give it a full earlycon line, I can't pin down whats going on with the PMU code until I fix the console.

About the only thing it says with any meaning when earlycon is passed is:

[   10.965147] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled
[   11.064193] dw-apb-uart APMC0D08:00: cannot get irq

and promptly hangs up.

I'm OOO for the next week, and will debug this further when I return if no one else makes any progress.

Quoted 4 lines · Jeremy Linton

I tried these patches on a m400 (which uses PPIs), and the kernel fails to come up enough to login via the network (which works with 4.11rc1 without these patches). So, I suspect there is something wrong with them.

Indeed; sorry about this. I'll see if I can get access to a board to try local debugging.

Quoted 5 lines

About the only thing it says with any meaning when earlycon is passed is:

[   10.965147] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled
[   11.064193] dw-apb-uart APMC0D08:00: cannot get irq

and promptly hangs up.

Quoted 15 lines · Mark Rutland

Quoted 4 lines · Jeremy Linton

I tried these patches on a m400 (which uses PPIs), and the kernel fails to come up enough to login via the network (which works with 4.11rc1 without these patches). So, I suspect there is something wrong with them.

Indeed; sorry about this. I'll see if I can get access to a board to try
local debugging.

Quoted 5 lines

About the only thing it says with any meaning when earlycon is passed is:

[   10.965147] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled
[   11.064193] dw-apb-uart APMC0D08:00: cannot get irq

and promptly hangs up.

I believe that this is a latent FW bug, in a beta FW, exposed by recent changes.

I managed to get access to two APM Mustang boards. I can reproduce the issue with a vanilla v4.11-rc1 defconfig on one, which has a beta FW. The same kernel boots fine on the other, which has a later released FW.

I bisected the issue down to commit:

d44fa3d46079dc09 ("ACPI: Add support for ResourceSource/IRQ domain
mapping")

It seems the beta FW describes the UART interrupt with an Extended Interrupt Descriptor with the Consumer/Producer bit clear. Per the spec,
this means "This device produces and consumes this resource", which doesn't make sense here given the UART is not an interrupt controller.

The (working) released FW doesn't use an Extended Interrupt Descriptor for this interrupt, sidestepping the issue.

Given that (AFAICT) this only affects a known-broken, beta FW, I don't think that we care that much.

However, I think there is a larger potential issue here.

In acpi_irq_parse_one_cb(), we skip interrupts with an Extended Interrupt Descriptor with the Consumer/Producer bit clear. It sounds like devices which behave as interrupt controllers could legitimately have this bit set for interrupts they generate and deliver to themselves, and we'd erroneously skip these when parsing interrupts.

It's not entirely clear to me why this bit exists at all, given that it's not used as part of mapping the interrupt, and if you really want to know you can map the interrupt and look at the result.

Hi Mark,

Quoted 49 lines · Mark Rutland

Quoted 6 lines · Mark Rutland

Quoted 4 lines · Jeremy Linton

I tried these patches on a m400 (which uses PPIs), and the kernel fails to come up enough to login via the network (which works with 4.11rc1 without these patches). So, I suspect there is something wrong with them.

Quoted 10 lines

Indeed; sorry about this. I'll see if I can get access to a board to try local debugging.

Quoted 1 line

About the only thing it says with any meaning when earlycon is

passed is:

Quoted 1 line

[   10.965147] Serial: 8250/16550 driver, 32 ports, IRQ sharing

enabled

Quoted 3 lines

[   11.064193] dw-apb-uart APMC0D08:00: cannot get irq

and promptly hangs up.

I believe that this is a latent FW bug, in a beta FW, exposed by recent changes.

I managed to get access to two APM Mustang boards. I can reproduce the issue with a vanilla v4.11-rc1 defconfig on one, which has a beta FW. The same kernel boots fine on the other, which has a later released FW.

I bisected the issue down to commit:

d44fa3d46079dc09 ("ACPI: Add support for ResourceSource/IRQ domain
mapping")

It seems the beta FW describes the UART interrupt with an Extended Interrupt Descriptor with the Consumer/Producer bit clear. Per the spec, this means "This device produces and consumes this resource", which doesn't make sense here given the UART is not an interrupt controller.

The (working) released FW doesn't use an Extended Interrupt Descriptor for this interrupt, sidestepping the issue.

Given that (AFAICT) this only affects a known-broken, beta FW, I don't think that we care that much.

However, I think there is a larger potential issue here.

In acpi_irq_parse_one_cb(), we skip interrupts with an Extended Interrupt Descriptor with the Consumer/Producer bit clear. It sounds like devices which behave as interrupt controllers could legitimately have this bit set for interrupts they generate and deliver to themselves, and we'd erroneously skip these when parsing interrupts.

Quoted 4 lines

It's not entirely clear to me why this bit exists at all, given that it's not used as part of mapping the interrupt, and if you really want to know you can map the interrupt and look at the result.

I think the best approach would be to try to amend the spec and make zero mean producer only which is the way it is being treated in Linux. That would mean that a device consuming its own interrupts would have to have two resources, one for describing the resource as producer and one as consumer.

Unfortunately the spec is vague in some areas like the feature we used to implement secondary IRQ controllers which require this patch.

Hanjun, can you bring this up at the next ASWG meeting? I don't normally attend but I will ask our ASWG lead to invite me so we can discuss this in that forum.

Quoted 14 lines · Mark Rutland

Quoted 4 lines · Jeremy Linton

I tried these patches on a m400 (which uses PPIs), and the kernel fails to come up enough to login via the network (which works with 4.11rc1 without these patches). So, I suspect there is something wrong with them.

Indeed; sorry about this. I'll see if I can get access to a board to try local debugging.

Quoted 5 lines

About the only thing it says with any meaning when earlycon is passed is:

[   10.965147] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled
[   11.064193] dw-apb-uart APMC0D08:00: cannot get irq

and promptly hangs up.

I believe that this is a latent FW bug, in a beta FW, exposed by recent changes.

I managed to get access to two APM Mustang boards. I can reproduce the issue with a vanilla v4.11-rc1 defconfig on one, which has a beta FW. The same kernel boots fine on the other, which has a later released FW.

I bisected the issue down to commit:

d44fa3d46079dc09 ("ACPI: Add support for ResourceSource/IRQ domain mapping")

It seems the beta FW describes the UART interrupt with an Extended Interrupt Descriptor with the Consumer/Producer bit clear. Per the spec, this means "This device produces and consumes this resource", which doesn't make sense here given the UART is not an interrupt controller.

The (working) released FW doesn't use an Extended Interrupt Descriptor for this interrupt, sidestepping the issue.

Given that (AFAICT) this only affects a known-broken, beta FW, I don't think that we care that much.

However, I think there is a larger potential issue here.

In acpi_irq_parse_one_cb(), we skip interrupts with an Extended Interrupt Descriptor with the Consumer/Producer bit clear. It sounds like devices which behave as interrupt controllers could legitimately have this bit set for interrupts they generate and deliver to themselves, and we'd erroneously skip these when parsing interrupts.

It's not entirely clear to me why this bit exists at all, given that it's not used as part of mapping the interrupt, and if you really want to know you can map the interrupt and look at the result.

Quoted 50 lines · Mark Rutland

Quoted 14 lines · Mark Rutland

Quoted 4 lines · Jeremy Linton

I tried these patches on a m400 (which uses PPIs), and the kernel fails to come up enough to login via the network (which works with 4.11rc1 without these patches). So, I suspect there is something wrong with them.

Indeed; sorry about this. I'll see if I can get access to a board to try local debugging.

Quoted 5 lines

About the only thing it says with any meaning when earlycon is passed is:

[   10.965147] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled
[   11.064193] dw-apb-uart APMC0D08:00: cannot get irq

and promptly hangs up.

I believe that this is a latent FW bug, in a beta FW, exposed by recent
changes.

I managed to get access to two APM Mustang boards. I can reproduce the issue with a vanilla v4.11-rc1 defconfig on one, which has a beta FW. The same kernel boots fine on the other, which has a later released FW.

I bisected the issue down to commit:

d44fa3d46079dc09 ("ACPI: Add support for ResourceSource/IRQ domain
mapping")

It seems the beta FW describes the UART interrupt with an Extended Interrupt Descriptor with the Consumer/Producer bit clear. Per the spec,
this means "This device produces and consumes this resource", which doesn't make sense here given the UART is not an interrupt controller.

The (working) released FW doesn't use an Extended Interrupt Descriptor for this interrupt, sidestepping the issue.

Given that (AFAICT) this only affects a known-broken, beta FW, I don't think that we care that much.

However, I think there is a larger potential issue here.

In acpi_irq_parse_one_cb(), we skip interrupts with an Extended Interrupt Descriptor with the Consumer/Producer bit clear. It sounds like devices which behave as interrupt controllers could legitimately have this bit set for interrupts they generate and deliver to themselves, and we'd erroneously skip these when parsing interrupts.

Quoted 3 lines

It's not entirely clear to me why this bit exists at all, given that it's not used as part of mapping the interrupt, and if you really want to know you can map the interrupt and look at the result.

It is not entirely clear to anyone (and it has been a source of major trouble for other descriptors - ie memory - to the point that it has been
deprecated for *some* descriptors). IIRC (Hanjun ?) the only reason why Agustin added the check for that bit in drivers/acpi/resource.c (is_gsi()) is to prevent ACPI core code allocating IRQs for the MBIgen device that, _erroneously_, was using an extended interrupt descriptor to list IRQ lines (that I have no idea what they represent) in order to count how many MSI vectors it would have to allocate.

The gist is: removing the check for the extended interrupt descriptor producer/consumer bit in ACPI code therefore ignoring that bit should be harmless (given that the MBIgen bindings should be changed anyway).

The meaning of that bit (and how we can flag up a FW bug) it is still a bit fuzzy IMO.

Agustin, Hanjun, comments ?

Quoted 46 lines · Mark Rutland

Quoted 14 lines · Mark Rutland

Quoted 4 lines · Jeremy Linton

I tried these patches on a m400 (which uses PPIs), and the kernel fails to come up enough to login via the network (which works with 4.11rc1 without these patches). So, I suspect there is something wrong with them.

Indeed; sorry about this. I'll see if I can get access to a board to try local debugging.

Quoted 5 lines

About the only thing it says with any meaning when earlycon is passed is:

[   10.965147] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled
[   11.064193] dw-apb-uart APMC0D08:00: cannot get irq

and promptly hangs up.

I believe that this is a latent FW bug, in a beta FW, exposed by recent changes.

I managed to get access to two APM Mustang boards. I can reproduce the issue with a vanilla v4.11-rc1 defconfig on one, which has a beta FW. The same kernel boots fine on the other, which has a later released FW.

I bisected the issue down to commit:

d44fa3d46079dc09 ("ACPI: Add support for ResourceSource/IRQ domain mapping")

It seems the beta FW describes the UART interrupt with an Extended Interrupt Descriptor with the Consumer/Producer bit clear. Per the spec, this means "This device produces and consumes this resource", which doesn't make sense here given the UART is not an interrupt controller.

The (working) released FW doesn't use an Extended Interrupt Descriptor for this interrupt, sidestepping the issue.

Given that (AFAICT) this only affects a known-broken, beta FW, I don't think that we care that much.

However, I think there is a larger potential issue here.

In acpi_irq_parse_one_cb(), we skip interrupts with an Extended Interrupt Descriptor with the Consumer/Producer bit clear. It sounds like devices which behave as interrupt controllers could legitimately have this bit set for interrupts they generate and deliver to themselves, and we'd erroneously skip these when parsing interrupts.

Quoted 3 lines

It's not entirely clear to me why this bit exists at all, given that it's not used as part of mapping the interrupt, and if you really want to know you can map the interrupt and look at the result.

It is not entirely clear to anyone (and it has been a source of major trouble for other descriptors - ie memory - to the point that it has been deprecated for *some* descriptors). IIRC (Hanjun ?) the only reason why Agustin added the check for that bit in drivers/acpi/resource.c (is_gsi()) is to prevent ACPI core code allocating IRQs for the MBIgen device that, _erroneously_, was using an extended interrupt descriptor to list IRQ lines (that I have no idea what they represent) in order to count how many MSI vectors it would have to allocate.

The gist is: removing the check for the extended interrupt descriptor producer/consumer bit in ACPI code therefore ignoring that bit should be harmless (given that the MBIgen bindings should be changed anyway).

The meaning of that bit (and how we can flag up a FW bug) it is still a bit fuzzy IMO.

Agustin, Hanjun, comments ?

Quoted 8 lines · Mark Rutland

I've given this some testing on a Juno platform (using SPIs). To see that IRQs are correctly associated, I've tested with the following:

 $ taskset -c ${SOME_CPU_HERE} perf record \
   -e armv8_pmuv3_0/cpu_cycles/ \
   -e armv8_pmuv3_1/cpu_cycles/ \
   cat /proc/interrupts

Quoted 3 lines

I've also booted with nr_cpus temporarily capped (passing maxcpus=) to test the association logic. This has also been tested in a VM using PPIs; I do not have access to a host machine which itself uses PPIs.

I tried these patches on a m400 (which uses PPIs), and the kernel fails to come up enough to login via the network (which works with 4.11rc1 without these patches). So, I suspect there is something wrong with them. Although its quite possibly PEBCAK.

Hi,

This series implements ACPI support in the ARM PMU code. It borrows some code from Jeremy's series [1], but takes a different approach to probing and association, using the usual hotplug state machine, minimising external changes required, and simplifying the relationship with the common arm_pmu code.

The first few patches are preparatory cleanup/refactoring, with the latter half of the series being specific to ACPI support.

The series is based on my IRQ rework patches [2]. I've pushed the whole series out to the arm/perf/acpi branch [3] of my kernel.org repo.

Due to the innards of the hotplug callback framework, it's not entirely safe to register a PMU in a hotplug callback. Due to this, we can only associated hotplugged CPUs with a PMU if a matching CPU was around at probe time. A similar restriction already applies to DT systems. We may be able to relax this with some future work.

I've given this some testing on a Juno platform (using SPIs). To see that IRQs are correctly associated, I've tested with the following:

  $ taskset -c ${SOME_CPU_HERE} perf record \
    -e armv8_pmuv3_0/cpu_cycles/ \
    -e armv8_pmuv3_1/cpu_cycles/ \
    cat /proc/interrupts

I've also booted with nr_cpus temporarily capped (passing maxcpus=) to test the association logic. This has also been tested in a VM using PPIs; I do not have access to a host machine which itself uses PPIs.

Quoted 22 lines · Mark Rutland

Hi,

This series implements ACPI support in the ARM PMU code. It borrows some code from Jeremy's series [1], but takes a different approach to probing and association, using the usual hotplug state machine, minimising external changes required, and simplifying the relationship with the common arm_pmu code.

The first few patches are preparatory cleanup/refactoring, with the latter half of the series being specific to ACPI support.

The series is based on my IRQ rework patches [2]. I've pushed the whole series out to the arm/perf/acpi branch [3] of my kernel.org repo.

Due to the innards of the hotplug callback framework, it's not entirely safe to register a PMU in a hotplug callback. Due to this, we can only associated hotplugged CPUs with a PMU if a matching CPU was around at probe time. A similar restriction already applies to DT systems. We may be able to relax this with some future work.

I've given this some testing on a Juno platform (using SPIs). To see that IRQs are correctly associated, I've tested with the following:

Quoted 8 lines

  $ taskset -c ${SOME_CPU_HERE} perf record \
    -e armv8_pmuv3_0/cpu_cycles/ \
    -e armv8_pmuv3_1/cpu_cycles/ \
    cat /proc/interrupts

I've also booted with nr_cpus temporarily capped (passing maxcpus=) to test the association logic. This has also been tested in a VM using PPIs; I do not have access to a host machine which itself uses PPIs.

Booted OK and 'perf list' got on Hisilicon D03:

d03-09:~ # perf list

List of pre-defined events (to be used in -e):

  branch-misses                                      [Hardware event]
  bus-cycles                                         [Hardware event]
  cache-misses                                       [Hardware event]
  cache-references                                   [Hardware event]
  cpu-cycles OR cycles                               [Hardware event]
  instructions                                       [Hardware event]

  alignment-faults                                   [Software event]
  context-switches OR cs                             [Software event]
  cpu-clock                                          [Software event]
  cpu-migrations OR migrations                       [Software event]
  dummy                                              [Software event]
  emulation-faults                                   [Software event]
  major-faults                                       [Software event]
  minor-faults                                       [Software event]
  page-faults OR faults                              [Software event]
  task-clock                                         [Software event]

  L1-dcache-load-misses                              [Hardware cache event]
  L1-dcache-loads                                    [Hardware cache event]
  L1-dcache-store-misses                             [Hardware cache event]
  L1-dcache-stores                                   [Hardware cache event]
  L1-icache-load-misses                              [Hardware cache event]
  L1-icache-loads                                    [Hardware cache event]
  branch-load-misses                                 [Hardware cache event]
  branch-loads                                       [Hardware cache event]
  dTLB-load-misses                                   [Hardware cache event]
  iTLB-load-misses                                   [Hardware cache event]

  armv8_pmuv3_0/br_mis_pred/                         [Kernel PMU event]
  armv8_pmuv3_0/br_pred/                             [Kernel PMU event]
  armv8_pmuv3_0/bus_access/                          [Kernel PMU event]
  armv8_pmuv3_0/bus_cycles/                          [Kernel PMU event]
  armv8_pmuv3_0/cid_write_retired/                   [Kernel PMU event]
  armv8_pmuv3_0/cpu_cycles/                          [Kernel PMU event]
  armv8_pmuv3_0/exc_return/                          [Kernel PMU event]
  armv8_pmuv3_0/exc_taken/                           [Kernel PMU event]
  armv8_pmuv3_0/inst_retired/                        [Kernel PMU event]
  armv8_pmuv3_0/inst_spec/                           [Kernel PMU event]
  armv8_pmuv3_0/l1d_cache/                           [Kernel PMU event]
  armv8_pmuv3_0/l1d_cache_refill/                    [Kernel PMU event]
  armv8_pmuv3_0/l1d_cache_wb/                        [Kernel PMU event]
  armv8_pmuv3_0/l1d_tlb_refill/                      [Kernel PMU event]
  armv8_pmuv3_0/l1i_cache/                           [Kernel PMU event]
  armv8_pmuv3_0/l1i_cache_refill/                    [Kernel PMU event]
  armv8_pmuv3_0/l1i_tlb_refill/                      [Kernel PMU event]
  armv8_pmuv3_0/l2d_cache/                           [Kernel PMU event]
  armv8_pmuv3_0/l2d_cache_refill/                    [Kernel PMU event]
  armv8_pmuv3_0/l2d_cache_wb/                        [Kernel PMU event]
  armv8_pmuv3_0/mem_access/                          [Kernel PMU event]
  armv8_pmuv3_0/memory_error/                        [Kernel PMU event]
  armv8_pmuv3_0/sw_incr/                             [Kernel PMU event]
  armv8_pmuv3_0/ttbr_write_retired/                  [Kernel PMU event]

rNNN [Raw hardware event descriptor]
cpu/t1=v1[,t2=v2,t3 ...]/modifier [Raw hardware event descriptor]
(see 'man perf-list' on how to encode it)

mem:<addr>[/len][:access] [Hardware breakpoint]

Try some basic perf event and it works, anything else I can try in specific?

Thanks
Hanjun

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Hi Hanjun,

Quoted 99 lines · Hanjun Guo

Quoted 22 lines · Mark Rutland

Hi,

This series implements ACPI support in the ARM PMU code. It borrows some code from Jeremy's series [1], but takes a different approach to probing and association, using the usual hotplug state machine, minimising external changes required, and simplifying the relationship with the common arm_pmu code.

The first few patches are preparatory cleanup/refactoring, with the latter half of the series being specific to ACPI support.

The series is based on my IRQ rework patches [2]. I've pushed the whole series out to the arm/perf/acpi branch [3] of my kernel.org repo.

Due to the innards of the hotplug callback framework, it's not entirely safe to register a PMU in a hotplug callback. Due to this, we can only associated hotplugged CPUs with a PMU if a matching CPU was around at probe time. A similar restriction already applies to DT systems. We may be able to relax this with some future work.

I've given this some testing on a Juno platform (using SPIs). To see that IRQs are correctly associated, I've tested with the following:

Quoted 8 lines

  $ taskset -c ${SOME_CPU_HERE} perf record \
    -e armv8_pmuv3_0/cpu_cycles/ \
    -e armv8_pmuv3_1/cpu_cycles/ \
    cat /proc/interrupts

I've also booted with nr_cpus temporarily capped (passing maxcpus=) to test the association logic. This has also been tested in a VM using PPIs; I do not have access to a host machine which itself uses PPIs.

Booted OK and 'perf list' got on Hisilicon D03:

d03-09:~ # perf list

List of pre-defined events (to be used in -e):

  branch-misses                                      [Hardware event]
  bus-cycles                                         [Hardware event]
  cache-misses                                       [Hardware event]
  cache-references                                   [Hardware event]
  cpu-cycles OR cycles                               [Hardware event]
  instructions                                       [Hardware event]

  alignment-faults                                   [Software event]
  context-switches OR cs                             [Software event]
  cpu-clock                                          [Software event]
  cpu-migrations OR migrations                       [Software event]
  dummy                                              [Software event]
  emulation-faults                                   [Software event]
  major-faults                                       [Software event]
  minor-faults                                       [Software event]
  page-faults OR faults                              [Software event]
  task-clock                                         [Software event]

  L1-dcache-load-misses                              [Hardware cache event]
  L1-dcache-loads                                    [Hardware cache event]
  L1-dcache-store-misses                             [Hardware cache event]
  L1-dcache-stores                                   [Hardware cache event]
  L1-icache-load-misses                              [Hardware cache event]
  L1-icache-loads                                    [Hardware cache event]
  branch-load-misses                                 [Hardware cache event]
  branch-loads                                       [Hardware cache event]
  dTLB-load-misses                                   [Hardware cache event]
  iTLB-load-misses                                   [Hardware cache event]

  armv8_pmuv3_0/br_mis_pred/                         [Kernel PMU event]
  armv8_pmuv3_0/br_pred/                             [Kernel PMU event]
  armv8_pmuv3_0/bus_access/                          [Kernel PMU event]
  armv8_pmuv3_0/bus_cycles/                          [Kernel PMU event]
  armv8_pmuv3_0/cid_write_retired/                   [Kernel PMU event]
  armv8_pmuv3_0/cpu_cycles/                          [Kernel PMU event]
  armv8_pmuv3_0/exc_return/                          [Kernel PMU event]
  armv8_pmuv3_0/exc_taken/                           [Kernel PMU event]
  armv8_pmuv3_0/inst_retired/                        [Kernel PMU event]
  armv8_pmuv3_0/inst_spec/                           [Kernel PMU event]
  armv8_pmuv3_0/l1d_cache/                           [Kernel PMU event]
  armv8_pmuv3_0/l1d_cache_refill/                    [Kernel PMU event]
  armv8_pmuv3_0/l1d_cache_wb/                        [Kernel PMU event]
  armv8_pmuv3_0/l1d_tlb_refill/                      [Kernel PMU event]
  armv8_pmuv3_0/l1i_cache/                           [Kernel PMU event]
  armv8_pmuv3_0/l1i_cache_refill/                    [Kernel PMU event]
  armv8_pmuv3_0/l1i_tlb_refill/                      [Kernel PMU event]
  armv8_pmuv3_0/l2d_cache/                           [Kernel PMU event]
  armv8_pmuv3_0/l2d_cache_refill/                    [Kernel PMU event]
  armv8_pmuv3_0/l2d_cache_wb/                        [Kernel PMU event]
  armv8_pmuv3_0/mem_access/                          [Kernel PMU event]
  armv8_pmuv3_0/memory_error/                        [Kernel PMU event]
  armv8_pmuv3_0/sw_incr/                             [Kernel PMU event]
  armv8_pmuv3_0/ttbr_write_retired/                  [Kernel PMU event]

rNNN [Raw hardware event descriptor]
cpu/t1=v1[,t2=v2,t3 ...]/modifier [Raw hardware event descriptor]
(see 'man perf-list' on how to encode it)

mem:<addr>[/len][:access] [Hardware breakpoint]

Quoted 1 line

Try some basic perf event and it works, anything else I can try in specific?

you can try perf fuzzer

thanks
Ganapat

Quoted 9 lines

Thanks
Hanjun

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

i am not able to run with latest perf tool, i see issue with memory corruption in malloc
is this seen from anyone else too?
i am not sure, is this issue with my setup?

root at VAL1-13>perf>> perf stat -e armv8_pmuv3_0/br_mis_pred/ sleep 1

Performance counter stats for 'sleep 1':

            10,815      armv8_pmuv3_0/br_mis_pred/

       1.001232167 seconds time elapsed

root at VAL1-13>perf>> ./perf stat -e armv8_pmuv3_0/br_mis_pred/ sleep 1 *** Error in `./perf': free(): invalid next size (fast): 0x00000000086a7a00 *** Aborted (core dumped)
root at VAL1-13>perf>> ./perf -v
perf version 4.11.rc3.g093b99
root at VAL1-13>perf>> perf -v
perf version 4.8.rc6.g21c488
root at VAL1-13>perf>> uname -a
Linux VAL1-13 4.11.0-rc2-12139-g3804e12 #1 SMP PREEMPT Wed Mar 22 06:26:28 UTC 2017 aarch64 aarch64 aarch64 GNU/Linux
root at VAL1-13>perf>>

i am not able to run with latest perf tool, i see issue with memory corruption in malloc
is this seen from anyone else too?
i am not sure, is this issue with my setup?

root at VAL1-13>perf>> perf stat -e armv8_pmuv3_0/br_mis_pred/ sleep 1

Performance counter stats for 'sleep 1':

            10,815      armv8_pmuv3_0/br_mis_pred/

       1.001232167 seconds time elapsed

root at VAL1-13>perf>> ./perf stat -e armv8_pmuv3_0/br_mis_pred/ sleep 1 *** Error in `./perf': free(): invalid next size (fast): 0x00000000086a7a00 *** Aborted (core dumped)
root at VAL1-13>perf>> ./perf -v
perf version 4.11.rc3.g093b99
root at VAL1-13>perf>> perf -v
perf version 4.8.rc6.g21c488
root at VAL1-13>perf>> uname -a
Linux VAL1-13 4.11.0-rc2-12139-g3804e12 #1 SMP PREEMPT Wed Mar 22 06:26:28 UTC 2017 aarch64 aarch64 aarch64 GNU/Linux
root at VAL1-13>perf>>

Quoted 114 lines · Ganapatrao Kulkarni

Hi Hanjun,

Quoted 92 lines · Hanjun Guo

Quoted 22 lines · Mark Rutland

Hi,

This series implements ACPI support in the ARM PMU code. It borrows some code from Jeremy's series [1], but takes a different approach to probing and association, using the usual hotplug state machine, minimising external changes required, and simplifying the relationship with the common arm_pmu code.

The first few patches are preparatory cleanup/refactoring, with the latter half of the series being specific to ACPI support.

The series is based on my IRQ rework patches [2]. I've pushed the whole series out to the arm/perf/acpi branch [3] of my kernel.org repo.

Due to the innards of the hotplug callback framework, it's not entirely safe to register a PMU in a hotplug callback. Due to this, we can only associated hotplugged CPUs with a PMU if a matching CPU was around at probe time. A similar restriction already applies to DT systems. We may be able to relax this with some future work.

I've given this some testing on a Juno platform (using SPIs). To see that IRQs are correctly associated, I've tested with the following:

Quoted 8 lines

  $ taskset -c ${SOME_CPU_HERE} perf record \
    -e armv8_pmuv3_0/cpu_cycles/ \
    -e armv8_pmuv3_1/cpu_cycles/ \
    cat /proc/interrupts

I've also booted with nr_cpus temporarily capped (passing maxcpus=) to test the association logic. This has also been tested in a VM using PPIs; I do not have access to a host machine which itself uses PPIs.

Booted OK and 'perf list' got on Hisilicon D03:

d03-09:~ # perf list

List of pre-defined events (to be used in -e):

  branch-misses                                      [Hardware event]
  bus-cycles                                         [Hardware event]
  cache-misses                                       [Hardware event]
  cache-references                                   [Hardware event]
  cpu-cycles OR cycles                               [Hardware event]
  instructions                                       [Hardware event]

  alignment-faults                                   [Software event]
  context-switches OR cs                             [Software event]
  cpu-clock                                          [Software event]
  cpu-migrations OR migrations                       [Software event]
  dummy                                              [Software event]
  emulation-faults                                   [Software event]
  major-faults                                       [Software event]
  minor-faults                                       [Software event]
  page-faults OR faults                              [Software event]
  task-clock                                         [Software event]

  L1-dcache-load-misses                              [Hardware cache event]
  L1-dcache-loads                                    [Hardware cache event]
  L1-dcache-store-misses                             [Hardware cache event]
  L1-dcache-stores                                   [Hardware cache event]
  L1-icache-load-misses                              [Hardware cache event]
  L1-icache-loads                                    [Hardware cache event]
  branch-load-misses                                 [Hardware cache event]
  branch-loads                                       [Hardware cache event]
  dTLB-load-misses                                   [Hardware cache event]
  iTLB-load-misses                                   [Hardware cache event]

  armv8_pmuv3_0/br_mis_pred/                         [Kernel PMU event]
  armv8_pmuv3_0/br_pred/                             [Kernel PMU event]
  armv8_pmuv3_0/bus_access/                          [Kernel PMU event]
  armv8_pmuv3_0/bus_cycles/                          [Kernel PMU event]
  armv8_pmuv3_0/cid_write_retired/                   [Kernel PMU event]
  armv8_pmuv3_0/cpu_cycles/                          [Kernel PMU event]
  armv8_pmuv3_0/exc_return/                          [Kernel PMU event]
  armv8_pmuv3_0/exc_taken/                           [Kernel PMU event]
  armv8_pmuv3_0/inst_retired/                        [Kernel PMU event]
  armv8_pmuv3_0/inst_spec/                           [Kernel PMU event]
  armv8_pmuv3_0/l1d_cache/                           [Kernel PMU event]
  armv8_pmuv3_0/l1d_cache_refill/                    [Kernel PMU event]
  armv8_pmuv3_0/l1d_cache_wb/                        [Kernel PMU event]
  armv8_pmuv3_0/l1d_tlb_refill/                      [Kernel PMU event]
  armv8_pmuv3_0/l1i_cache/                           [Kernel PMU event]
  armv8_pmuv3_0/l1i_cache_refill/                    [Kernel PMU event]
  armv8_pmuv3_0/l1i_tlb_refill/                      [Kernel PMU event]
  armv8_pmuv3_0/l2d_cache/                           [Kernel PMU event]
  armv8_pmuv3_0/l2d_cache_refill/                    [Kernel PMU event]
  armv8_pmuv3_0/l2d_cache_wb/                        [Kernel PMU event]
  armv8_pmuv3_0/mem_access/                          [Kernel PMU event]
  armv8_pmuv3_0/memory_error/                        [Kernel PMU event]
  armv8_pmuv3_0/sw_incr/                             [Kernel PMU event]
  armv8_pmuv3_0/ttbr_write_retired/                  [Kernel PMU event]

Quoted 8 lines

rNNN [Raw hardware event descriptor]
cpu/t1=v1[,t2=v2,t3 ...]/modifier [Raw hardware event descriptor]
(see 'man perf-list' on how to encode it)

mem:<addr>[/len][:access] [Hardware breakpoint]

Try some basic perf event and it works, anything else I can try in specific?

you can try perf fuzzer

thanks
Ganapat

Quoted 5 lines

Thanks
Hanjun

Quoted 4 lines

Quoted 4 lines

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

thanks
Ganapat

Quoted 13 lines · Ganapatrao Kulkarni

i am not able to run with latest perf tool, i see issue with memory corruption in malloc
is this seen from anyone else too?
i am not sure, is this issue with my setup?

root at VAL1-13>perf>> perf stat -e armv8_pmuv3_0/br_mis_pred/ sleep 1

Performance counter stats for 'sleep 1':

            10,815      armv8_pmuv3_0/br_mis_pred/

       1.001232167 seconds time elapsed

Quoted 11 lines

root at VAL1-13>perf>> ./perf stat -e armv8_pmuv3_0/br_mis_pred/ sleep 1 *** Error in `./perf': free(): invalid next size (fast): 0x00000000086a7a00 *** Aborted (core dumped)
root at VAL1-13>perf>> ./perf -v
perf version 4.11.rc3.g093b99
root at VAL1-13>perf>> perf -v
perf version 4.8.rc6.g21c488
root at VAL1-13>perf>> uname -a
Linux VAL1-13 4.11.0-rc2-12139-g3804e12 #1 SMP PREEMPT Wed Mar 22 06:26:28 UTC 2017 aarch64 aarch64 aarch64 GNU/Linux
root at VAL1-13>perf>>

i did bisect, and i see your patch,

7e3fcffe955440101493cd8f32f75840ddf87b6f
perf pmu: Support alternative sysfs cpumask

is causing this failure. if i suppress the call to function cpu_map__read then memory corruption is not seen.

Hi Hanjun,

Quoted 95 lines · Hanjun Guo

Quoted 22 lines · Mark Rutland

Hi,

This series implements ACPI support in the ARM PMU code. It borrows some code from Jeremy's series [1], but takes a different approach to probing and association, using the usual hotplug state machine, minimising external changes required, and simplifying the relationship with the common arm_pmu code.

The first few patches are preparatory cleanup/refactoring, with the latter half of the series being specific to ACPI support.

The series is based on my IRQ rework patches [2]. I've pushed the whole series out to the arm/perf/acpi branch [3] of my kernel.org repo.

Due to the innards of the hotplug callback framework, it's not entirely safe to register a PMU in a hotplug callback. Due to this, we can only associated hotplugged CPUs with a PMU if a matching CPU was around at probe time. A similar restriction already applies to DT systems. We may be able to relax this with some future work.

I've given this some testing on a Juno platform (using SPIs). To see that IRQs are correctly associated, I've tested with the following:

Quoted 8 lines

  $ taskset -c ${SOME_CPU_HERE} perf record \
    -e armv8_pmuv3_0/cpu_cycles/ \
    -e armv8_pmuv3_1/cpu_cycles/ \
    cat /proc/interrupts

I've also booted with nr_cpus temporarily capped (passing maxcpus=) to test the association logic. This has also been tested in a VM using PPIs; I do not have access to a host machine which itself uses PPIs.

Booted OK and 'perf list' got on Hisilicon D03:

d03-09:~ # perf list

List of pre-defined events (to be used in -e):

  branch-misses                                      [Hardware event]
  bus-cycles                                         [Hardware event]
  cache-misses                                       [Hardware event]
  cache-references                                   [Hardware event]
  cpu-cycles OR cycles                               [Hardware event]
  instructions                                       [Hardware event]

  alignment-faults                                   [Software event]
  context-switches OR cs                             [Software event]
  cpu-clock                                          [Software event]
  cpu-migrations OR migrations                       [Software event]
  dummy                                              [Software event]
  emulation-faults                                   [Software event]
  major-faults                                       [Software event]
  minor-faults                                       [Software event]
  page-faults OR faults                              [Software event]
  task-clock                                         [Software event]

  L1-dcache-load-misses                              [Hardware cache event]
  L1-dcache-loads                                    [Hardware cache event]
  L1-dcache-store-misses                             [Hardware cache event]
  L1-dcache-stores                                   [Hardware cache event]
  L1-icache-load-misses                              [Hardware cache event]
  L1-icache-loads                                    [Hardware cache event]
  branch-load-misses                                 [Hardware cache event]
  branch-loads                                       [Hardware cache event]
  dTLB-load-misses                                   [Hardware cache event]
  iTLB-load-misses                                   [Hardware cache event]

  armv8_pmuv3_0/br_mis_pred/                         [Kernel PMU event]
  armv8_pmuv3_0/br_pred/                             [Kernel PMU event]
  armv8_pmuv3_0/bus_access/                          [Kernel PMU event]
  armv8_pmuv3_0/bus_cycles/                          [Kernel PMU event]
  armv8_pmuv3_0/cid_write_retired/                   [Kernel PMU event]
  armv8_pmuv3_0/cpu_cycles/                          [Kernel PMU event]
  armv8_pmuv3_0/exc_return/                          [Kernel PMU event]
  armv8_pmuv3_0/exc_taken/                           [Kernel PMU event]
  armv8_pmuv3_0/inst_retired/                        [Kernel PMU event]
  armv8_pmuv3_0/inst_spec/                           [Kernel PMU event]
  armv8_pmuv3_0/l1d_cache/                           [Kernel PMU event]
  armv8_pmuv3_0/l1d_cache_refill/                    [Kernel PMU event]
  armv8_pmuv3_0/l1d_cache_wb/                        [Kernel PMU event]
  armv8_pmuv3_0/l1d_tlb_refill/                      [Kernel PMU event]
  armv8_pmuv3_0/l1i_cache/                           [Kernel PMU event]
  armv8_pmuv3_0/l1i_cache_refill/                    [Kernel PMU event]
  armv8_pmuv3_0/l1i_tlb_refill/                      [Kernel PMU event]
  armv8_pmuv3_0/l2d_cache/                           [Kernel PMU event]
  armv8_pmuv3_0/l2d_cache_refill/                    [Kernel PMU event]
  armv8_pmuv3_0/l2d_cache_wb/                        [Kernel PMU event]
  armv8_pmuv3_0/mem_access/                          [Kernel PMU event]
  armv8_pmuv3_0/memory_error/                        [Kernel PMU event]
  armv8_pmuv3_0/sw_incr/                             [Kernel PMU event]
  armv8_pmuv3_0/ttbr_write_retired/                  [Kernel PMU event]

rNNN [Raw hardware event descriptor]
cpu/t1=v1[,t2=v2,t3 ...]/modifier [Raw hardware event descriptor]
(see 'man perf-list' on how to encode it)

Quoted 4 lines

mem:<addr>[/len][:access] [Hardware breakpoint]

Try some basic perf event and it works, anything else I can try in specific?

you can try perf fuzzer

Hi,

This series implements ACPI support in the ARM PMU code. It borrows some code from Jeremy's series [1], but takes a different approach to probing and association, using the usual hotplug state machine, minimising external changes required, and simplifying the relationship with the common arm_pmu code.

The first few patches are preparatory cleanup/refactoring, with the latter half of the series being specific to ACPI support.

The series is based on my IRQ rework patches [2]. I've pushed the whole series out to the arm/perf/acpi branch [3] of my kernel.org repo.

Due to the innards of the hotplug callback framework, it's not entirely safe to register a PMU in a hotplug callback. Due to this, we can only associated hotplugged CPUs with a PMU if a matching CPU was around at probe time. A similar restriction already applies to DT systems. We may be able to relax this with some future work.

I've given this some testing on a Juno platform (using SPIs). To see that IRQs are correctly associated, I've tested with the following:

  $ taskset -c ${SOME_CPU_HERE} perf record \
    -e armv8_pmuv3_0/cpu_cycles/ \
    -e armv8_pmuv3_1/cpu_cycles/ \
    cat /proc/interrupts

I've also booted with nr_cpus temporarily capped (passing maxcpus=) to test the association logic. This has also been tested in a VM using PPIs; I do not have access to a host machine which itself uses PPIs.

Thanks,
Mark.

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2017-January/482397.html
[2] http://lists.infradead.org/pipermail/linux-arm-kernel/2017-March/492891.html
[3] git://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git arm/perf/acpi

Mark Rutland (14):
drivers/perf: arm_pmu: remove pointless PMU disabling drivers/perf: arm_pmu: define armpmu_init_fn drivers/perf: arm_pmu: fold init into alloc drivers/perf: arm_pmu: factor out pmu registration drivers/perf: arm_pmu: simplify cpu_pmu_request_irqs() drivers/perf: arm_pmu: handle no platform_device drivers/perf: arm_pmu: rename irq request/free functions drivers/perf: arm_pmu: split cpu-local irq request/free drivers/perf: arm_pmu: move irq request/free into probe drivers/perf: arm_pmu: split out platform device probe logic
arm64: add function to get a cpu's MADT GICC table
arm64: kill acpi_set_mailbox_entry()
drivers/perf: arm_pmu: add ACPI framework
arm64: pmuv3: use arm_pmu ACPI framework

 arch/arm64/include/asm/acpi.h             |   7 +-
 arch/arm64/kernel/acpi_parking_protocol.c |  38 +--
 arch/arm64/kernel/perf_event.c            |  26 +-
 arch/arm64/kernel/smp.c                   |  19 +-
 drivers/perf/Kconfig                      |   4 +
 drivers/perf/Makefile                     |   3 +-
 drivers/perf/arm_pmu.c                    | 383 ++++++++----------------------
 drivers/perf/arm_pmu_acpi.c               | 237 ++++++++++++++++++
 drivers/perf/arm_pmu_platform.c           | 235 ++++++++++++++++++
 include/linux/cpuhotplug.h                |   1 +
 include/linux/perf/arm_pmu.h              |  22 +-
 11 files changed, 626 insertions(+), 349 deletions(-)
 create mode 100644 drivers/perf/arm_pmu_acpi.c
 create mode 100644 drivers/perf/arm_pmu_platform.c

I've been testing these on a few machines (m400 & dual socket cavium for starters) over the last few days. So far everything seems to be working fine excepting the usual set of strange messages from the perf fuzzer.

Tested-by Jeremy Linton <[email protected]>

Hi Jeremy,

Quoted 5 lines · Jeremy Linton

I've been testing these on a few machines (m400 & dual socket cavium for starters) over the last few days. So far everything seems to be working fine excepting the usual set of strange messages from the perf fuzzer.

Quoted 1 line

Tested-by Jeremy Linton <[email protected]>

Thanks for giving this a go, especially with the fuzzer!

Just to check, should that email be jeremy.linton at arm.com, or is that an alias that also works? I've added it as-is for the moment.