| Message ID | 20200624195811.435857-1-maz@kernel.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | arm/arm64: Turning IPIs into normal interrupts | expand |
Hi Marc, On 24/06/20 20:57, Marc Zyngier wrote: > For as long as SMP ARM has existed, IPIs have been handled as > something special. The arch code and the interrupt controller exchange > a couple of hooks (one to generate an IPI, another to handle it). > > Although this is perfectly manageable, it prevents the use of features > that we could use if IPIs were Linux IRQs (such as pseudo-NMIs). It > also means that each interrupt controller driver has to follow an > architecture-specific interface instead of just implementing the base > irqchip functionalities. The arch code also duplicates a number of > things that the core irq code already does (such as calling > set_irq_regs(), irq_enter()...). > > This series tries to remedy this on arm/arm64 by offering a new > registration interface where the irqchip gives the arch code a range > of interrupts to use for IPIs. The arch code requests these as normal > per-cpu interrupts. > > The bulk of the work is at the interrupt controller level, where all 5 > irqchips used on arm+SMP/arm64 get converted. > > Finally, we drop the legacy registration interface as well as the > custom statistics accounting. > > Note that I have had a look at providing a "generic" interface by > expanding the kernel/irq/ipi.c bag of helpers, but so far all > irqchips have very different requirements, so there is hardly anything > to consolidate for now. Maybe some as hip04 and the Marvell horror get > cleaned up (the latter certainly could do with a good dusting). > > This has been tested on a bunch of 32 and 64bit guests (GICv2, GICv3), > as well as 64bit bare metal (GICv3). The RPi part has only been tested > in QEMU as a 64bit guest, while the HiSi and Marvell parts have only > been compile-tested. > I gave that a spin on Juno r0 and HiKey960 (both GICv2), all good! I also wanted to try it out on my eMAG (to get some GICv3 airtime) but ran into "technical difficulties". I think I'll need to get someone to go poke it (most likely next week). I'm pretty sure I'm the one who should be asking you for hardware, but if there's anything specific you need me to test, please shout. I have a few extra nits/comments in some patches, but it's all fairly minor so FWIW you can also add, for patches [01-10, 14-15]: Reviewed-by: Valentin Schneider <valentin.schneider@arm.com> I haven't really looked at those other irqchips, but I can give it a shot if no one else shows up. Also I'll most likely look at the arm side, but I'm afraid I'm too well-done right now to pay much more attention to details.
On 25/06/20 19:24, Valentin Schneider wrote: > I have a few extra nits/comments in some patches, but it's all fairly minor > so FWIW you can also add, for patches [01-10, 14-15]: > > Reviewed-by: Valentin Schneider <valentin.schneider@arm.com> > > I haven't really looked at those other irqchips, but I can give it a shot > if no one else shows up. Also I'll most likely look at the arm side, but > I'm afraid I'm too well-done right now to pay much more attention to > details. Had a look at the arm side (and a took a refresher on the arm64 side); LGTM, so you can extend that to: [01-10, 14-17].
Hi Marc, On Thu, 25 Jun 2020 at 01:28, Marc Zyngier <maz@kernel.org> wrote: > > For as long as SMP ARM has existed, IPIs have been handled as > something special. The arch code and the interrupt controller exchange > a couple of hooks (one to generate an IPI, another to handle it). > > Although this is perfectly manageable, it prevents the use of features > that we could use if IPIs were Linux IRQs (such as pseudo-NMIs). It > also means that each interrupt controller driver has to follow an > architecture-specific interface instead of just implementing the base > irqchip functionalities. The arch code also duplicates a number of > things that the core irq code already does (such as calling > set_irq_regs(), irq_enter()...). > > This series tries to remedy this on arm/arm64 by offering a new > registration interface where the irqchip gives the arch code a range > of interrupts to use for IPIs. The arch code requests these as normal > per-cpu interrupts. > > The bulk of the work is at the interrupt controller level, where all 5 > irqchips used on arm+SMP/arm64 get converted. > > Finally, we drop the legacy registration interface as well as the > custom statistics accounting. > > Note that I have had a look at providing a "generic" interface by > expanding the kernel/irq/ipi.c bag of helpers, but so far all > irqchips have very different requirements, so there is hardly anything > to consolidate for now. Maybe some as hip04 and the Marvell horror get > cleaned up (the latter certainly could do with a good dusting). > > This has been tested on a bunch of 32 and 64bit guests (GICv2, GICv3), > as well as 64bit bare metal (GICv3). The RPi part has only been tested > in QEMU as a 64bit guest, while the HiSi and Marvell parts have only > been compile-tested. This series works perfectly fine on Developerbox. I just want to follow-up regarding when you are planning to push this series upstream? Are you waiting for other irqchips (apart from GIC) to be reviewed? Actually mine work to turn IPI as a pseudo NMI [1] is dependent on this patch-set. [1] https://lkml.org/lkml/2020/5/20/488 -Sumit > > * From v1: > - Clarified the effect of nesting irq_enter/exit (Russell) > - Changed the point where we tear IPIs down on (Valentin) > - IPIs are no longer accessible from DT > - HIP04 and Armada 370-XP have been converted, but are untested > - arch-specific kstat accounting is removed > - ARM's legacy interface is dropped > > Marc Zyngier (17): > genirq: Add fasteoi IPI flow > genirq: Allow interrupts to be excluded from /proc/interrupts > arm64: Allow IPIs to be handled as normal interrupts > ARM: Allow IPIs to be handled as normal interrupts > irqchip/gic-v3: Describe the SGI range > irqchip/gic-v3: Configure SGIs as standard interrupts > irqchip/gic: Atomically update affinity > irqchip/gic: Refactor SMP configuration > irqchip/gic: Configure SGIs as standard interrupts > irqchip/gic-common: Don't enable SGIs by default > irqchip/bcm2836: Configure mailbox interrupts as standard interrupts > irqchip/hip04: Configure IPIs as standard interrupts > irqchip/armada-370-xp: Configure IPIs as standard interrupts > arm64: Kill __smp_cross_call and co > arm64: Remove custom IRQ stat accounting > ARM: Kill __smp_cross_call and co > ARM: Remove custom IRQ stat accounting > > arch/arm/Kconfig | 1 + > arch/arm/include/asm/hardirq.h | 17 -- > arch/arm/include/asm/smp.h | 5 +- > arch/arm/kernel/smp.c | 135 +++++++++----- > arch/arm64/Kconfig | 1 + > arch/arm64/include/asm/hardirq.h | 9 - > arch/arm64/include/asm/irq_work.h | 4 +- > arch/arm64/include/asm/smp.h | 6 +- > arch/arm64/kernel/smp.c | 119 ++++++++----- > drivers/irqchip/irq-armada-370-xp.c | 262 +++++++++++++++++++--------- > drivers/irqchip/irq-bcm2836.c | 151 +++++++++++++--- > drivers/irqchip/irq-gic-common.c | 3 - > drivers/irqchip/irq-gic-v3.c | 99 ++++++----- > drivers/irqchip/irq-gic.c | 183 ++++++++++--------- > drivers/irqchip/irq-hip04.c | 89 +++++----- > include/linux/irq.h | 5 +- > kernel/irq/chip.c | 27 +++ > kernel/irq/debugfs.c | 1 + > kernel/irq/proc.c | 2 +- > kernel/irq/settings.h | 7 + > 20 files changed, 713 insertions(+), 413 deletions(-) > > -- > 2.27.0 >
Hi Sumit, On 2020-08-11 14:15, Sumit Garg wrote: > Hi Marc, > > On Thu, 25 Jun 2020 at 01:28, Marc Zyngier <maz@kernel.org> wrote: >> >> For as long as SMP ARM has existed, IPIs have been handled as >> something special. The arch code and the interrupt controller exchange >> a couple of hooks (one to generate an IPI, another to handle it). >> >> Although this is perfectly manageable, it prevents the use of features >> that we could use if IPIs were Linux IRQs (such as pseudo-NMIs). It >> also means that each interrupt controller driver has to follow an >> architecture-specific interface instead of just implementing the base >> irqchip functionalities. The arch code also duplicates a number of >> things that the core irq code already does (such as calling >> set_irq_regs(), irq_enter()...). >> >> This series tries to remedy this on arm/arm64 by offering a new >> registration interface where the irqchip gives the arch code a range >> of interrupts to use for IPIs. The arch code requests these as normal >> per-cpu interrupts. >> >> The bulk of the work is at the interrupt controller level, where all 5 >> irqchips used on arm+SMP/arm64 get converted. >> >> Finally, we drop the legacy registration interface as well as the >> custom statistics accounting. >> >> Note that I have had a look at providing a "generic" interface by >> expanding the kernel/irq/ipi.c bag of helpers, but so far all >> irqchips have very different requirements, so there is hardly anything >> to consolidate for now. Maybe some as hip04 and the Marvell horror get >> cleaned up (the latter certainly could do with a good dusting). >> >> This has been tested on a bunch of 32 and 64bit guests (GICv2, GICv3), >> as well as 64bit bare metal (GICv3). The RPi part has only been tested >> in QEMU as a 64bit guest, while the HiSi and Marvell parts have only >> been compile-tested. > > This series works perfectly fine on Developerbox. > > I just want to follow-up regarding when you are planning to push this > series upstream? Are you waiting for other irqchips (apart from GIC) > to be reviewed? I'd certainly like people to review (and maybe test if they have the HW at hand) the rest of the interrupt controller changes. I'll probably repost the series around -rc1. > Actually mine work to turn IPI as a pseudo NMI [1] is dependent on > this patch-set. > > [1] https://lkml.org/lkml/2020/5/20/488 I'm aware of this. Thanks, M.