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

[Mark Salter]

On Wed, 2014-03-19 at 10:57 +0000, Catalin Marinas wrote:
> 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.

How about this?

diff --git a/arch/arm64/kernel/efi-entry.S b/arch/arm64/kernel/efi-entry.S
index 83bfb72..ed480b2 100644
--- a/arch/arm64/kernel/efi-entry.S
+++ b/arch/arm64/kernel/efi-entry.S
@@ -52,11 +52,19 @@ ENTRY(efi_stub_entry)
 	 * efi_entry() will have relocated the kernel image if necessary
 	 * and we return here with device tree address in x0 and the kernel
 	 * entry point stored at *image_addr. Save those values in registers
-	 * which are preserved by __flush_dcache_all.
+	 * which are callee preserved.
 	 */
-	ldr	x1, [sp, #16]
 	mov	x20, x0
-	mov	x21, x1
+	ldr	x0, [sp, #16]
+	mov	x21, x0
+
+	adrp	x1, _text
+	add	x1, x1, #:lo12:_text
+	adrp	x2, _edata
+	add	x2, x2, #:lo12:_edata
+	sub	x1, x2, x1
+
+	bl	__flush_dcache_area
 
 	/* Turn off Dcache and MMU */
 	mrs	x0, CurrentEL
@@ -76,8 +84,6 @@ ENTRY(efi_stub_entry)
 	msr	sctlr_el1, x0
 	isb
 2:
-	bl	__flush_dcache_all
-
 	/* Jump to real entry point */
 	mov	x0, x20
 	mov	x1, xzr



--
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/