lkml.org 
[lkml]   [2014]   [Mar]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
SubjectRe: [PATCH v2 11/15] arm64: add EFI stub
From
Date
On Wed, 2014-03-19 at 16:01 +0000, Catalin Marinas wrote:
> On Wed, Mar 19, 2014 at 03:13:18PM +0000, Mark Salter wrote:
> > 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
>
> BTW, some comments to make it easier to review the code later about
> what's at [sp, #16].

Okay.

>
> > +
> > + adrp x1, _text
> > + add x1, x1, #:lo12:_text
> > + adrp x2, _edata
> > + add x2, x2, #:lo12:_edata
> > + sub x1, x2, x1
> > +
> > + bl __flush_dcache_area
>
> Looks fine. We also need a "ic ialluis", is any other part of EFI_STUB
> invalidating the I-cache?

No. I will add it.





\
 
 \ /
  Last update: 2014-03-19 18:41    [W:0.045 / U:0.500 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site