Thread (1 message) 1 message, 1 author, 2021-02-08

Re: [PATCH 10/18] arm64: Introduce FIQ support

From: Hector Martin <hidden>
Date: 2021-02-08 23:35:19
Also in: linux-arm-kernel, lkml

Possibly related (same subject, not in this thread)

On 08/02/2021 03.49, Arnd Bergmann wrote:
Ok, I had not realized the timer was level triggered. In case of the
timer, I suppose it could be either masked or acknowledged from the
fiq top-half handler when deferring to irq, but I agree that it means a
layering violation in either case.

What might still work is an approach where FIQ is normally enabled,
and local_irq_disable() leaves it on, while local_irq_enable() turns
it on regardless of the current state.

In this case, the fiq handler could run the timer function if interrupts
are enabled but just turn off fiqs when they are turned off, waiting
for the next local_irq_enable() to get us back in the state where
the handler can run.  Not sure if that would buy us anything though,
or if that still requires platform specific conditionals in common code.
It looks like Marc is just leaning towards making the IRQ and FIQ masks 
track each other unconditionally on all platforms anyway, so I'm going 
to try that for v2 (which is certainly the simpler solution). If this 
ends up somehow breaking any other platform we can deal with it in the 
way that makes most sense, once we know how it breaks :)
quoted
* An exception seems to be non-HV timer interrupts firing while we have
a VM guest running (HCR_EL2.TGE=0). This causes a single FIQ, and no
more, which suggests there is a mask bit for guest timer FIQs somewhere
that gets automatically set when the FIQ is delivered to the CPU core.
I've yet to find where this bit lives, I'll be doing a brute force sweep
of system register space soon to see if I can find it, and if there is
anything else useful near it.
Right. Maybe you can even find a bit that switches between FIQ and
IRQ mode for the timer, as that would solve the problem completely.
I think it's not that rare for irqchips to be configurable to either route
an interrupt one way or the other.
That seems increasingly unlikely here; I tried poking all the AIC config 
bits and nothing switched those to FIQ (which is the converse). It looks 
like Apple has done something like use FIQ for all core-internal 
interrupt sources, and IRQ for AIC, and this is all seemingly quite 
hardwired.

In particular, a subtlety I discovered about how flipping TGE to 1 with 
a guest timer interrupt pending only takes effect properly (i.e. FIQ 
fires, and you get a FIQ storm if unhandled, no auto-masking) after 
subsequently issuing an isb, makes me think all this FIQ stuff is 
seriously deeply tied into the instruction pipeline. It's probably not 
an IRQ line any more...

-- 
Hector Martin (marcan@marcan.st)
Public Key: https://mrcn.st/pub
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help