From: Marc Zyngier <maz@kernel.org>
To: Florian Fainelli <f.fainelli@gmail.com>
Cc: Sumit Garg <sumit.garg@linaro.org>,
Russell King <linux@arm.linux.org.uk>,
Jason Cooper <jason@lakedaemon.net>,
Will Deacon <will@kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>,
linux-kernel@vger.kernel.org,
Thomas Gleixner <tglx@linutronix.de>,
kernel-team@android.com, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 00/11] arm/arm64: Turning IPIs into normal interrupts
Date: Fri, 12 Jun 2020 10:49:18 +0100 [thread overview]
Message-ID: <20200612104918.3829bb26@why> (raw)
In-Reply-To: <d1ac7873-0f02-dbe0-dd3c-4fd14a87cf03@gmail.com>
Hi Florian,
On Tue, 19 May 2020 10:50:46 -0700
Florian Fainelli <f.fainelli@gmail.com> wrote:
> On 5/19/2020 9:17 AM, 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 functionnalities. 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
> > interrupts.
> >
> > The bulk of the work is at the interrupt controller level, where all 3
> > irqchips used on arm64 get converted.
> >
> > Finally, the arm64 code drops the legacy registration interface. The
> > same thing could be done on 32bit as well once the two remaining
> > irqchips using that interface get converted.
> >
> > There is probably more that could be done: statistics are still
> > architecture-private code, for example, and no attempt is made to
> > solve that (apart from hidding the IRQs from /proc/interrupt).
> >
> > This has been tested on a bunch of 32 and 64bit guests.
>
> Does this patch series change your position on this patch series
>
> https://lore.kernel.org/linux-arm-kernel/20191023000547.7831-3-f.fainelli@gmail.com/T/
>
> or is this still a no-no?
I don't think this series changes anything. There is no easy way to
reserve SGIs in a way that would work for all combination of OS and FW,
and the prospect of sending SGIs between S and NS has already been
dubious (yes, the GIC architecture allows it, but it has been written
by people who have never designed any large piece of SW).
Thanks,
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Florian Fainelli <f.fainelli@gmail.com>
Cc: linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Sumit Garg <sumit.garg@linaro.org>,
kernel-team@android.com, Russell King <linux@arm.linux.org.uk>,
Jason Cooper <jason@lakedaemon.net>,
Catalin Marinas <catalin.marinas@arm.com>,
Thomas Gleixner <tglx@linutronix.de>,
Will Deacon <will@kernel.org>
Subject: Re: [PATCH 00/11] arm/arm64: Turning IPIs into normal interrupts
Date: Fri, 12 Jun 2020 10:49:18 +0100 [thread overview]
Message-ID: <20200612104918.3829bb26@why> (raw)
In-Reply-To: <d1ac7873-0f02-dbe0-dd3c-4fd14a87cf03@gmail.com>
Hi Florian,
On Tue, 19 May 2020 10:50:46 -0700
Florian Fainelli <f.fainelli@gmail.com> wrote:
> On 5/19/2020 9:17 AM, 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 functionnalities. 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
> > interrupts.
> >
> > The bulk of the work is at the interrupt controller level, where all 3
> > irqchips used on arm64 get converted.
> >
> > Finally, the arm64 code drops the legacy registration interface. The
> > same thing could be done on 32bit as well once the two remaining
> > irqchips using that interface get converted.
> >
> > There is probably more that could be done: statistics are still
> > architecture-private code, for example, and no attempt is made to
> > solve that (apart from hidding the IRQs from /proc/interrupt).
> >
> > This has been tested on a bunch of 32 and 64bit guests.
>
> Does this patch series change your position on this patch series
>
> https://lore.kernel.org/linux-arm-kernel/20191023000547.7831-3-f.fainelli@gmail.com/T/
>
> or is this still a no-no?
I don't think this series changes anything. There is no easy way to
reserve SGIs in a way that would work for all combination of OS and FW,
and the prospect of sending SGIs between S and NS has already been
dubious (yes, the GIC architecture allows it, but it has been written
by people who have never designed any large piece of SW).
Thanks,
M.
--
Jazz is not dead. It just smells funny...
next prev parent reply other threads:[~2020-06-12 9:49 UTC|newest]
Thread overview: 72+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-19 16:17 [PATCH 00/11] arm/arm64: Turning IPIs into normal interrupts Marc Zyngier
2020-05-19 16:17 ` Marc Zyngier
2020-05-19 16:17 ` [PATCH 01/11] genirq: Add fasteoi IPI flow Marc Zyngier
2020-05-19 16:17 ` Marc Zyngier
2020-05-19 19:47 ` Florian Fainelli
2020-05-19 19:47 ` Florian Fainelli
2020-06-12 9:54 ` Marc Zyngier
2020-06-12 9:54 ` Marc Zyngier
2020-05-19 22:25 ` Valentin Schneider
2020-05-19 22:25 ` Valentin Schneider
2020-05-19 22:29 ` Valentin Schneider
2020-05-19 22:29 ` Valentin Schneider
2020-06-12 9:58 ` Marc Zyngier
2020-06-12 9:58 ` Marc Zyngier
2020-05-19 16:17 ` [PATCH 02/11] genirq: Allow interrupts to be excluded from /proc/interrupts Marc Zyngier
2020-05-19 16:17 ` Marc Zyngier
2020-05-19 16:17 ` [PATCH 03/11] arm64: Allow IPIs to be handled as normal interrupts Marc Zyngier
2020-05-19 16:17 ` Marc Zyngier
2020-05-21 14:03 ` Valentin Schneider
2020-05-21 14:03 ` Valentin Schneider
2020-05-19 16:17 ` [PATCH 04/11] ARM: " Marc Zyngier
2020-05-19 16:17 ` Marc Zyngier
2020-05-19 22:24 ` Russell King - ARM Linux admin
2020-05-19 22:24 ` Russell King - ARM Linux admin
2020-05-21 14:03 ` Valentin Schneider
2020-05-21 14:03 ` Valentin Schneider
2020-05-21 15:12 ` Russell King - ARM Linux admin
2020-05-21 15:12 ` Russell King - ARM Linux admin
2020-05-21 16:11 ` Valentin Schneider
2020-05-21 16:11 ` Valentin Schneider
2020-05-19 16:17 ` [PATCH 05/11] irqchip/gic-v3: Describe the SGI range Marc Zyngier
2020-05-19 16:17 ` Marc Zyngier
2020-05-19 16:17 ` [PATCH 06/11] irqchip/gic-v3: Configure SGIs as standard interrupts Marc Zyngier
2020-05-19 16:17 ` Marc Zyngier
2020-05-20 9:52 ` Sumit Garg
2020-05-20 9:52 ` Sumit Garg
2020-05-20 10:24 ` Marc Zyngier
2020-05-20 10:24 ` Marc Zyngier
2020-05-21 14:04 ` Valentin Schneider
2020-05-21 14:04 ` Valentin Schneider
2020-06-12 10:39 ` Marc Zyngier
2020-06-12 10:39 ` Marc Zyngier
2020-05-19 16:17 ` [PATCH 07/11] irqchip/gic: Refactor SMP configuration Marc Zyngier
2020-05-19 16:17 ` Marc Zyngier
2020-05-19 16:17 ` [PATCH 08/11] irqchip/gic: Configure SGIs as standard interrupts Marc Zyngier
2020-05-19 16:17 ` Marc Zyngier
2021-04-20 20:37 ` dann frazier
2021-04-20 20:37 ` dann frazier
2021-04-20 21:25 ` dann frazier
2021-04-20 21:25 ` dann frazier
2021-04-21 10:58 ` Marc Zyngier
2021-04-21 10:58 ` Marc Zyngier
2021-04-21 14:52 ` dann frazier
2021-04-21 14:52 ` dann frazier
2021-04-21 15:49 ` Marc Zyngier
2021-04-21 15:49 ` Marc Zyngier
2020-05-19 16:17 ` [PATCH 09/11] irqchip/gic-common: Don't enable SGIs by default Marc Zyngier
2020-05-19 16:17 ` Marc Zyngier
2020-05-19 16:17 ` [PATCH 10/11] irqchip/bcm2836: Configure mailbox interrupts as standard interrupts Marc Zyngier
2020-05-19 16:17 ` Marc Zyngier
2020-05-19 16:17 ` [PATCH 11/11] arm64: Kill __smp_cross_call and co Marc Zyngier
2020-05-19 16:17 ` Marc Zyngier
2020-05-19 17:50 ` [PATCH 00/11] arm/arm64: Turning IPIs into normal interrupts Florian Fainelli
2020-05-19 17:50 ` Florian Fainelli
2020-05-19 19:47 ` Florian Fainelli
2020-05-19 19:47 ` Florian Fainelli
2020-06-12 9:49 ` Marc Zyngier [this message]
2020-06-12 9:49 ` Marc Zyngier
2020-06-12 16:57 ` Florian Fainelli
2020-06-12 16:57 ` Florian Fainelli
2020-05-19 22:25 ` Valentin Schneider
2020-05-19 22:25 ` Valentin Schneider
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200612104918.3829bb26@why \
--to=maz@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=f.fainelli@gmail.com \
--cc=jason@lakedaemon.net \
--cc=kernel-team@android.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=sumit.garg@linaro.org \
--cc=tglx@linutronix.de \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.