[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <jhjmu4rgg04.mognet@arm.com>
Date: Thu, 25 Jun 2020 19:24:59 +0100
From: Valentin Schneider <valentin.schneider@....com>
To: Marc Zyngier <maz@...nel.org>
Cc: linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
Will Deacon <will@...nel.org>,
Catalin Marinas <catalin.marinas@....com>,
Russell King <linux@....linux.org.uk>,
Thomas Gleixner <tglx@...utronix.de>,
Jason Cooper <jason@...edaemon.net>,
Sumit Garg <sumit.garg@...aro.org>,
Florian Fainelli <f.fainelli@...il.com>,
Gregory Clement <gregory.clement@...tlin.com>,
Andrew Lunn <andrew@...n.ch>, kernel-team@...roid.com
Subject: Re: [PATCH v2 00/17] arm/arm64: Turning IPIs into normal interrupts
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@....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.
Powered by blists - more mailing lists