On Sat, Feb 6, 2021 at 4:37 PM Marc Zyngier [off-list ref] wrote:

On Thu, 04 Feb 2021 20:39:43 +0000, Hector Martin [off-list ref] wrote:

quoted

diff --git a/arch/arm64/include/asm/assembler.h b/arch/arm64/include/asm/assembler.h
index bf125c591116..6acfc372dc76 100644
--- a/arch/arm64/include/asm/assembler.h
+++ b/arch/arm64/include/asm/assembler.h

@@ -42,7 +42,11 @@

      /* IRQ is the lowest priority flag, unconditionally unmask the rest. */
      .macro enable_da_f
+alternative_if ARM64_NEEDS_FIQ
+     msr     daifclr, #(8 | 4)
+alternative_else
      msr     daifclr, #(8 | 4 | 1)
+alternative_endif

See my digression in patch 8. I really wonder what the benefit is to
treat FIQ independently of IRQ, and we might as well generalise
this. We could always panic on getting a FIQ on platforms that don't
expect one.

It'd be good to rope in the other interested parties (Mark for the
early entry code, James for RAS and SError handling).

There might be another slightly hacky but less intrusive option
that could be done (almost) purely within the aic code:

* In the fiq handler code, check if normal interrupts were enabled
  when the fiq hit. Normally they are enabled, so just proceed to
  handle the timer and ipi directly

* if irq was disabled, defer the handling by doing a self-ipi
  through the aic's ipi method, and handle it from there
  when dealing with the next interrupt once interrupts get
  enabled.

This would be similar to the soft-disable feature on powerpc, which
never actually turns off interrupts from regular kernel code but
just checks a flag in local_irq_enable that gets set when a
hardirq happened.

          Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel