Messages in this thread | | | Date | Wed, 24 Feb 2021 14:06:56 +0000 | From | Mark Rutland <> | Subject | Re: [PATCH 0/8] arm64: Support FIQ controller registration |
| |
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.
I guess we could take that as a prerequisite ahead of the rest?
Thanks, Mark.
| |