On Sun, 07 Feb 2021 08:47:23 +0000,
Hector Martin 'marcan' [off-list ref] wrote:

On 07/02/2021 00.37, Marc Zyngier wrote:

quoted

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).

CCing Mark and James: TL;DR what do you think about unconditionally
keeping DAIF.I == DAIF.F, would this break other platforms with
spurious FIQs or conversely mask FIQs when we don't want to in some
cases? The FIQ vector would remain a panic except on platforms that
require using it, via an alternatives patch.

quoted

quoted

  	kernel_ventry	1, sync				// Synchronous EL1h
  	kernel_ventry	1, irq				// IRQ EL1h
-	kernel_ventry	1, fiq_invalid			// FIQ EL1h
+							// FIQ EL1h
+	kernel_ventry	1, fiq_invalid, 64, irq, ARM64_NEEDS_FIQ

It could be better to create a set of first class FIQ handlers rather
than this alternative target macro. I quickly hacked this instead,
which I find more readable.

I think I ended up with the macro change to keep it 1:1 with IRQ, vs a
separate branch... but I didn't think of the fallthrough-with-nop
trick, neat. It is definitely is more readable. Are you OK with me
pulling this patch in for v2, with your name on it?

Up to you, I don't mind either way. This is just code! :D

quoted

-	kernel_ventry	0, fiq_invalid_compat, 32	// FIQ 32-bit EL0
+	kernel_ventry	0, fiq, 32			// FIQ 32-bit EL0

fiq_compat here, right?

Of course.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.

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