aarch64: support FIQs and use them for TLB shootdown IPIs

[NathanRoyer]

Sometimes when we tried spawning an interactive console in theseus on aarch64, by sending keystrokes through the UART port, theseus hanged.

We then found out that a complicated scenario was taking place:

• the console task was spawned and scheduled but the sub-tasks it spawned in turn were not running
• in fact two of the four cores were stopped, so they were ghosting the tasks randomly assigned to them...
• they were stopped because they tried to broadcast an interrupt to other cores, which is an NMI on x86 but I had implemented it as a regular interrupt on aarch64, early in the port process, without leaving a clear TODO/warning... big mistake: the two missing cores were silently clashing on this
• I reimplemented this using fast interrupts, which highlighted some other bugs but ultimately fixed the issue

This brings the following changes:

• The interrupt controller API only contains cross-platform features, other features are not part of the trait. This made it easier to support FIQs on aarch64, but it could become a separate trait: Aarch64LocalInterruptController.
• Aarch64-specific methods of the LocalInterruptController allow configuring/handling fast interrupts (FIQs).
• The interrupt controller now allows enabling/disabling SPIs too (this was missing).
• The GIC driver was updated with Group 0 (used by FIQs) interrupt support.
• A bug in memory_aarch64 was fixed (a shift operation was missing).
• A silent bug recently introduced in context_switch_regular was fixed (incorrect structure size assumption, fixed by padding the structure, which makes the assembly and memory layout easier to understand).
• The interrupts crate was modified to handle FIQs.
• The TLB Shootdown crate now uses FIQs on aarch64 as an NMI alternative.
• nano_core, captain and ap_start were modified to set FIQ masks correctly.

This depend on a PR in irq_safety, so it doesn't build at this moment.

[kevinaboos]

Dealing with FIQs is kind of annoying. I'm wondering if we should just create a separate/dedicated struct or series of functions for handling FIQs that doesn't go through the same LocalInterruptController API that regular IRQs do.

[NathanRoyer]

Dealing with FIQs is kind of annoying. I'm wondering if we should just create a separate/dedicated struct or series of functions for handling FIQs that doesn't go through the same LocalInterruptController API that regular IRQs do.

If there was only GICv3 we could, but as GICv2 uses MMIO for FIQ management I think we should keep this "Use the normal structures but bypass their sync primitives" design: it's pretty simple to understand, unsafe code is very small, and it retains GIC compatibility via the GICv2/GICv3 abstraction.

[kevinaboos]

Dealing with FIQs is kind of annoying. I'm wondering if we should just create a separate/dedicated struct or series of functions for handling FIQs that doesn't go through the same LocalInterruptController API that regular IRQs do.

If there was only GICv3 we could, but as GICv2 uses MMIO for FIQ management I think we should keep this "Use the normal structures but bypass their sync primitives" design: it's pretty simple to understand, unsafe code is very small, and it retains GIC compatibility via the GICv2/GICv3 abstraction.

Fair enough, I agree.

Left a few new comments, should be easy to address pretty quickly.

[kevinaboos]

I've accepted this PR, thanks! A couple of follow-up changes I'd like to see:

• InterruptDestination seems redundant with IpiTargetCpu...?

• We can use type wrappers to ensure that the acknowledge_fast_interrupt and end_of_fast_interrupt functions are only invokable by current_elx_fiq. By that I mean create a new type ExceptionContextFiq that is a simple wrapper around ExceptionContext, and then require a reference to that type to be passed into both of the above fast interrupt functions. Then, we can make those functions safe on the outside, and just use unsafe on the inside.

  #[transparent]
  #[non_exhaustive]
  pub struct ExceptionContextFiq(ExceptionContext);

  This design is better imo since there's no real way to ensure that the fast interrupt functions are actually called safely.

• It's a little bit odd to use the type *const InterruptHandler, since InterruptHandler is already a function pointer. We should be able to remove the leading *const part and just deal with the InterruptHandler directly. But do let me know if that is actually requried somewhere else.