linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: msalter@redhat.com (Mark Salter)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 11/15] arm64: add EFI stub
Date: Wed, 19 Mar 2014 12:46:52 -0400	[thread overview]
Message-ID: <1395247612.2967.53.camel@deneb.redhat.com> (raw)
In-Reply-To: <20140319160149.GF2214@arm.com>

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.

  reply	other threads:[~2014-03-19 16:46 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-13 22:46 [PATCH v2 00/14] UEFI support for arm(64) Leif Lindholm
2014-03-13 22:46 ` [PATCH v2 01/15] efi: delete stray ARM ifdef Leif Lindholm
2014-03-13 22:46 ` [PATCH v2 02/15] efi: x86: Improve cmdline conversion Leif Lindholm
2014-03-13 22:46 ` [PATCH v2 03/15] efi: create memory map iteration helper Leif Lindholm
2014-03-13 22:46 ` [PATCH v2 04/15] lib: add fdt_empty_tree.c Leif Lindholm
2014-03-13 22:46 ` [PATCH v2 05/15] efi: add helper function to get UEFI params from FDT Leif Lindholm
2014-03-13 22:46 ` [PATCH v2 06/15] doc: efi-stub.txt updates for ARM Leif Lindholm
2014-03-13 22:47 ` [PATCH v2 07/15] efi: Add shared printk wrapper for consistent prefixing Leif Lindholm
2014-03-13 22:47 ` [PATCH v2 08/15] efi: Add get_dram_base() helper function Leif Lindholm
2014-03-13 22:47 ` [PATCH v2 09/15] efi: Add shared FDT related functions for ARM/ARM64 Leif Lindholm
2014-03-13 22:47 ` [PATCH v2 10/15] arm64: Add function to create identity mappings Leif Lindholm
2014-03-13 22:47 ` [PATCH v2 11/15] arm64: add EFI stub Leif Lindholm
2014-03-18 12:09   ` Catalin Marinas
2014-03-18 14:40     ` Mark Salter
2014-03-18 18:28       ` Catalin Marinas
2014-03-18 21:40         ` Mark Salter
2014-03-18 21:48           ` Roy Franz
2014-03-18 22:21             ` Jason Gunthorpe
2014-03-19 10:35               ` Catalin Marinas
2014-03-19 10:57           ` Catalin Marinas
2014-03-19 15:13             ` Mark Salter
2014-03-19 16:01               ` Catalin Marinas
2014-03-19 16:46                 ` Mark Salter [this message]
2014-03-13 22:47 ` [PATCH v2 12/15] doc: arm64: add description of EFI stub support Leif Lindholm
2014-03-13 22:47 ` [PATCH v2 13/15] arm64: add EFI runtime services Leif Lindholm
2014-03-18 12:34   ` Catalin Marinas
2014-03-18 14:16     ` Mark Salter
2014-03-18 17:36       ` Catalin Marinas
2014-03-13 22:47 ` [PATCH v2 14/15] doc: arm: add UEFI support documentation Leif Lindholm
2014-03-13 22:47 ` [PATCH v2 15/15] efi/arm64: ignore dtb= when UEFI SecureBoot is enabled Leif Lindholm
2014-03-17 22:24 ` [PATCH v2 00/14] UEFI support for arm(64) Matt Fleming

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1395247612.2967.53.camel@deneb.redhat.com \
    --to=msalter@redhat.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).