Re: [PATCH v2 11/15] arm64: add EFI stub

[Catalin Marinas]

On Tue, Mar 18, 2014 at 09:40:31PM +0000, Mark Salter wrote:
> On Tue, 2014-03-18 at 18:28 +0000, Catalin Marinas wrote:
> > If UEFI doesn't handle the caches, the only thing left to EFI_STUB is to
> > flush by MVA. We don't need to flush the whole DRAM (and I would even
> > recommend it) but at least the relevant kernel code/data touched with
> > the MMU disabled.
> 
> So, it goes like this:
> 
>   1) UEFI calls stub with MMU/Caches on. Stub/kernel can be anywhere.
>   2) Stub runs and relocates kernel to the desired runtime location
>      but continues to execute from wherever UEFI loaded it until just
>      after ExitBootServices().
>   3) After ExitBootServices, efi_entry() returns relocated entry point
>      for kernel to efi_stub_entry() in efi-entry.S where the Dcache and
>      MMU are turned off, the __flush_dcache_all is called, then the
>      code jumps to the kernel proper entry point.
> 
> It isn't clear to me if UEFI does cache flushing at ExitBootServices
> time, but even so, at least stack use will get cached between then and
> the kernel entry point. The stub could conceivably get its hands on the
> EFI memmap and invalidate dcache using address ranges from UEFI memory
> descriptors so maybe that is the way we should do it.

I think the stub just needs to flush the relocated kernel image, ensure
it is sync with the memory. Additional flushing can be done by the
kernel for bits it writes (like page tables, code patching etc). We can
enter the kernel with the SCTLR.I bit set, so it can allocate in an
unified cache already and D-cache maintenance would be needed anyway.

Another aspect in the booting document is that we require any external
cache to be disabled. I think on ARMv8 with a more transparent external
cache we can relax this (Applied's SoC already does this). Otherwise,
since external cache enabling is usually a secure operation, we would
need some SoC specific code just for this early during boot and I'd like
to avoid it.

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/