From: Marc Zyngier <maz@kernel.org> To: Mark Rutland <mark.rutland@arm.com> Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, catalin.marinas@arm.com, james.morse@arm.com, marcan@marcan.st, tglx@linutronix.de, will@kernel.org Subject: Re: [PATCH 0/8] arm64: Support FIQ controller registration Date: Wed, 24 Feb 2021 14:32:05 +0000 [thread overview] Message-ID: <f69e51e4161f48442933c0c5296b313d@kernel.org> (raw) In-Reply-To: <20210224140656.GG50741@C02TD0UTHF1T.local> On 2021-02-24 14:06, Mark Rutland wrote: > On Fri, Feb 19, 2021 at 06:10:56PM +0000, Marc Zyngier wrote: >> Hi Mark, >> >> On Fri, 19 Feb 2021 11:38:56 +0000, >> Mark Rutland <mark.rutland@arm.com> wrote: >> > >> > Hector's M1 support series [1] shows that some platforms have critical >> > interrupts wired to FIQ, and to support these platforms we need to support >> > handling FIQ exceptions. Other contemporary platforms don't use FIQ (since e.g. >> > this is usually routed to EL3), and as we never expect to take an FIQ, we have >> > the FIQ vector cause a panic. >> > >> > Since the use of FIQ is a platform integration detail (which can differ across >> > bare-metal and virtualized environments), we need be able to explicitly opt-in >> > to handling FIQs while retaining the existing behaviour otherwise. This series >> > adds a new set_handle_fiq() hook so that the FIQ controller can do so, and >> > where no controller is registered the default handler will panic(). For >> > consistency the set_handle_irq() code is made to do the same. >> > >> > The first couple of patches are from Marc's irq/drop-generic_irq_multi_handler >> > branch [2] on kernel.org, and clean up CONFIG_GENERIC_IRQ_MULTI_HANDLER usage. >> > The next four patches move arm64 over to a local set_handle_irq() >> > implementation, which is written to share code with a set_handle_fiq() function >> > in the last two patches. The only functional difference here is that if an IRQ >> > is somehow taken prior to set_handle_irq() the default handler will directly >> > panic() rather than the vector branching to NULL. >> > >> > The penultimate patch is cherry-picked from the v2 M1 series, and as per >> > discussion there [3] will need a few additional fixups. I've included it for >> > now as the DAIF.IF alignment is necessary for the FIQ exception handling added >> > in the final patch. >> > >> > The final patch adds the low-level FIQ exception handling and registration >> > mechanism atop the prior rework. >> >> Thanks for putting this together. I have an extra patch on top of this >> series[1] that prevents the kernel from catching fire if a FIQ fires >> whilst running a guest. Nothing urgent, we can queue it at a later >> time. >> >> Thanks, >> >> M. >> >> [1] >> https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/log/?h=irq/fiq > > IIUC for that "invalid_vect" should be changed to "valid_vect", to > match > the other valid vector entries, but otherwise that looks sane to me. Err, yes. I though I had fixed that, but obviously didn't. > I guess we could take that as a prerequisite ahead of the rest? Sure, that's mostly independent anyway. And it would make more sense for an unexpected FIQ to crash the host at at the point where we handle interrupts rather than in KVM with very little debug information. Thanks, M. -- Jazz is not dead. It just smells funny...
WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org> To: Mark Rutland <mark.rutland@arm.com> Cc: catalin.marinas@arm.com, marcan@marcan.st, linux-kernel@vger.kernel.org, james.morse@arm.com, tglx@linutronix.de, will@kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH 0/8] arm64: Support FIQ controller registration Date: Wed, 24 Feb 2021 14:32:05 +0000 [thread overview] Message-ID: <f69e51e4161f48442933c0c5296b313d@kernel.org> (raw) In-Reply-To: <20210224140656.GG50741@C02TD0UTHF1T.local> On 2021-02-24 14:06, Mark Rutland wrote: > On Fri, Feb 19, 2021 at 06:10:56PM +0000, Marc Zyngier wrote: >> Hi Mark, >> >> On Fri, 19 Feb 2021 11:38:56 +0000, >> Mark Rutland <mark.rutland@arm.com> wrote: >> > >> > Hector's M1 support series [1] shows that some platforms have critical >> > interrupts wired to FIQ, and to support these platforms we need to support >> > handling FIQ exceptions. Other contemporary platforms don't use FIQ (since e.g. >> > this is usually routed to EL3), and as we never expect to take an FIQ, we have >> > the FIQ vector cause a panic. >> > >> > Since the use of FIQ is a platform integration detail (which can differ across >> > bare-metal and virtualized environments), we need be able to explicitly opt-in >> > to handling FIQs while retaining the existing behaviour otherwise. This series >> > adds a new set_handle_fiq() hook so that the FIQ controller can do so, and >> > where no controller is registered the default handler will panic(). For >> > consistency the set_handle_irq() code is made to do the same. >> > >> > The first couple of patches are from Marc's irq/drop-generic_irq_multi_handler >> > branch [2] on kernel.org, and clean up CONFIG_GENERIC_IRQ_MULTI_HANDLER usage. >> > The next four patches move arm64 over to a local set_handle_irq() >> > implementation, which is written to share code with a set_handle_fiq() function >> > in the last two patches. The only functional difference here is that if an IRQ >> > is somehow taken prior to set_handle_irq() the default handler will directly >> > panic() rather than the vector branching to NULL. >> > >> > The penultimate patch is cherry-picked from the v2 M1 series, and as per >> > discussion there [3] will need a few additional fixups. I've included it for >> > now as the DAIF.IF alignment is necessary for the FIQ exception handling added >> > in the final patch. >> > >> > The final patch adds the low-level FIQ exception handling and registration >> > mechanism atop the prior rework. >> >> Thanks for putting this together. I have an extra patch on top of this >> series[1] that prevents the kernel from catching fire if a FIQ fires >> whilst running a guest. Nothing urgent, we can queue it at a later >> time. >> >> Thanks, >> >> M. >> >> [1] >> https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/log/?h=irq/fiq > > IIUC for that "invalid_vect" should be changed to "valid_vect", to > match > the other valid vector entries, but otherwise that looks sane to me. Err, yes. I though I had fixed that, but obviously didn't. > I guess we could take that as a prerequisite ahead of the rest? Sure, that's mostly independent anyway. And it would make more sense for an unexpected FIQ to crash the host at at the point where we handle interrupts rather than in KVM with very little debug information. 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
next prev parent reply other threads:[~2021-02-24 15:15 UTC|newest] Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-02-19 11:38 [PATCH 0/8] arm64: Support FIQ controller registration Mark Rutland 2021-02-19 11:38 ` Mark Rutland 2021-02-19 11:38 ` [PATCH 1/8] ARM: ep93xx: Select GENERIC_IRQ_MULTI_HANDLER directly Mark Rutland 2021-02-19 11:38 ` Mark Rutland 2021-02-19 11:38 ` [PATCH 2/8] irqchip: Do not blindly select CONFIG_GENERIC_IRQ_MULTI_HANDLER Mark Rutland 2021-02-19 11:38 ` Mark Rutland 2021-02-19 11:38 ` [PATCH 3/8] genirq: Allow architectures to override set_handle_irq() fallback Mark Rutland 2021-02-19 11:38 ` Mark Rutland 2021-02-19 11:39 ` [PATCH 4/8] arm64: don't use GENERIC_IRQ_MULTI_HANDLER Mark Rutland 2021-02-19 11:39 ` Mark Rutland 2021-02-19 11:39 ` [PATCH 5/8] arm64: irq: add a default handle_irq panic function Mark Rutland 2021-02-19 11:39 ` Mark Rutland 2021-02-22 9:59 ` Mark Rutland 2021-02-22 9:59 ` Mark Rutland 2021-02-22 10:48 ` Marc Zyngier 2021-02-22 10:48 ` Marc Zyngier 2021-02-22 11:25 ` Mark Rutland 2021-02-22 11:25 ` Mark Rutland 2021-02-22 11:43 ` Marc Zyngier 2021-02-22 11:43 ` Marc Zyngier 2021-02-22 12:06 ` Mark Rutland 2021-02-22 12:06 ` Mark Rutland 2021-02-22 12:23 ` Marc Zyngier 2021-02-22 12:23 ` Marc Zyngier 2021-02-19 11:39 ` [PATCH 6/8] arm64: entry: factor irq triage logic into macros Mark Rutland 2021-02-19 11:39 ` Mark Rutland 2021-02-19 11:39 ` [PATCH 7/8] arm64: Always keep DAIF.[IF] in sync Mark Rutland 2021-02-19 11:39 ` Mark Rutland 2021-02-19 17:25 ` [PATCH 7/8 v1.5] " Hector Martin 2021-02-19 17:25 ` Hector Martin 2021-02-19 18:26 ` Mark Rutland 2021-02-19 18:26 ` Mark Rutland 2021-02-22 17:39 ` Hector Martin 2021-02-22 17:39 ` Hector Martin 2021-02-22 18:43 ` Mark Rutland 2021-02-22 18:43 ` Mark Rutland 2021-02-19 11:39 ` [PATCH 8/8] arm64: irq: allow FIQs to be handled Mark Rutland 2021-02-19 11:39 ` Mark Rutland 2021-02-19 15:37 ` Joey Gouly 2021-02-19 15:37 ` Joey Gouly 2021-02-19 18:18 ` Mark Rutland 2021-02-19 18:18 ` Mark Rutland 2021-02-19 15:41 ` [PATCH 0/8] arm64: Support FIQ controller registration Hector Martin 2021-02-19 15:41 ` Hector Martin 2021-02-19 16:13 ` Mark Rutland 2021-02-19 16:13 ` Mark Rutland 2021-02-19 18:10 ` Marc Zyngier 2021-02-19 18:10 ` Marc Zyngier 2021-02-24 14:06 ` Mark Rutland 2021-02-24 14:06 ` Mark Rutland 2021-02-24 14:32 ` Marc Zyngier [this message] 2021-02-24 14:32 ` Marc Zyngier
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=f69e51e4161f48442933c0c5296b313d@kernel.org \ --to=maz@kernel.org \ --cc=catalin.marinas@arm.com \ --cc=james.morse@arm.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=marcan@marcan.st \ --cc=mark.rutland@arm.com \ --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: linkBe 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.