On 07/02/2021 00.37, Marc Zyngier wrote:
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.
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?
- kernel_ventry 0, fiq_invalid_compat, 32 // FIQ 32-bit EL0
+ kernel_ventry 0, fiq, 32 // FIQ 32-bit EL0
fiq_compat here, right?
--
Hector Martin "marcan" (marcan@xxxxxxxxx)
Public Key: https://mrcn.st/pub
