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-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
