[RFC PATCH] arm64: use non-global mappings for UEFI runtime regions

[Mark Rutland]

> >> > For backporting, I'm not sure that this is necessarily safe prior to
> >> > Will's rework of the ASID allocator. I think we can IPI in this context,
> >> > and it looks like the cpu_set_reserved_ttbr0() in flush_context() would
> >> > save us from the problem described above, but I may have missed
> >> > something.
> >> >
> >> > Will, are you aware of anything that could bite us here?
> >>
> >> Can we guarantee that efi_virtmap_{load,unload} are called with interrupts
> >> enabled?
> >
> > Unfortuantely, it looks like we can guarantee interrupts are _disabled_.
> >
> > Every function in drivers/firmware/efi/runtime-wrappers.c which uses
> > efi_call_virt (and hence efi_virtmap_{load,unload}) wraps the call in a
> > spin_lock_irq{save,restore} pair. Those appear to be the only uses of
> > efi_call_virt.
> >
> 
> There is actually no need from the UEFI pov to invoke the UEFI runtime
> services with interrupts disabled, this is simply an implementation
> detail of the kernel support, and I think it is primarily for x86 (but
> I have to dig up the old thread for the details)
> 
> And even if we stick with spin_lock_irqsave(), we could refactor the
> runtime wrappers to perform the mm switch outside of them.

Ok.

I'm only thinking about stable here.

In the context of a stable backport, I think the simplest thing to do is
always go via the resesrved ttbr0 to perform the TLB flush, and
hand-code the save/restore of the active mm's TTBR0_EL1 value rather
than going through cpu_switch_mm (which I believe we can't call with
interrupts disabled).

It doesn't look like it's easy to stash the value given
efi_virtmap_{load,unload} are separate functions, and I don't think we
can just restore from current->active_mm in case there was a concurrent
rollover on another CPU.

Mark.