public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: mark.rutland@arm.com (Mark Rutland)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 3/7] arm64: split off early mapping code from early_fixmap_init()
Date: Thu, 3 Dec 2015 12:18:40 +0000	[thread overview]
Message-ID: <20151203121840.GB28731@leverpostej> (raw)
In-Reply-To: <1447672998-20981-4-git-send-email-ard.biesheuvel@linaro.org>

Hi Ard,

Apologies that it's taken me so long to get around to this...

On Mon, Nov 16, 2015 at 12:23:14PM +0100, Ard Biesheuvel wrote:
> This splits off and generalises the population of the statically
> allocated fixmap page tables so that we may reuse it later for
> the linear mapping once we move the kernel text mapping out of it.
> 
> This also involves taking into account that table entries at any of
> the levels we are populating may have been populated already, since
> the fixmap mapping might not be disjoint up to the pgd level anymore
> from other early mappings.

As a heads-up, for avoiding TLB conflicts, I'm currently working on
alternative way of creating the kernel page tables which will definitely
conflict here, and may or may not supercede this approach.

By adding new FIX_{PGD,PUD,PMD,PTE} indicees to the fixmap, we can
allocate page tables from anywhere via memblock, and temporarily map
them as we need to.

That would avoid the need for the bootstrap tables. In head.S we'd only
need to create a temporary (coarse-grained, RWX) kernel mapping (with
the fixmap bolted on). Later we would create a whole new set of tables
with a fine-grained kernel mapping and a full linear mapping using the
new fixmap entries to temporarily map tables, then switch over to those
atomically.

Otherwise, one minor comment below.

> +static void __init bootstrap_early_mapping(unsigned long addr,
> +					   struct bootstrap_pgtables *reg,
> +					   bool pte_level)

The only caller in this patch passes true for pte_level.

Can we not introduce the argument when it is first needed? Or at least
have something in the commit message as to why we'll need it later?

>  	/*
>  	 * The boot-ioremap range spans multiple pmds, for which
> -	 * we are not preparted:
> +	 * we are not prepared:
>  	 */

I cannot wait to see this typo go!

Otherwise, this looks fine to me.

Thanks,
Mark.

  reply	other threads:[~2015-12-03 12:18 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-16 11:23 [PATCH v3 0/7] arm64: relax Image placement rules Ard Biesheuvel
2015-11-16 11:23 ` [PATCH v3 1/7] of/fdt: make memblock minimum physical address arch configurable Ard Biesheuvel
2015-11-16 11:23 ` [PATCH v3 2/7] arm64: use more granular reservations for static page table allocations Ard Biesheuvel
2015-11-16 11:23 ` [PATCH v3 3/7] arm64: split off early mapping code from early_fixmap_init() Ard Biesheuvel
2015-12-03 12:18   ` Mark Rutland [this message]
2015-12-03 13:31     ` Ard Biesheuvel
2015-12-03 13:59       ` Mark Rutland
2015-12-03 14:05         ` Ard Biesheuvel
2015-12-07 16:08       ` Catalin Marinas
2015-12-07 16:13         ` Ard Biesheuvel
2015-12-08 12:40     ` Will Deacon
2015-12-08 13:29       ` Ard Biesheuvel
2015-12-08 13:51         ` Will Deacon
2015-12-15 19:19           ` Ard Biesheuvel
2015-11-16 11:23 ` [PATCH v3 4/7] arm64: mm: explicitly bootstrap the linear mapping Ard Biesheuvel
2015-11-16 11:23 ` [PATCH v3 5/7] arm64: move kernel mapping out of linear region Ard Biesheuvel
2015-12-07 12:26   ` Catalin Marinas
2015-12-07 12:33     ` Ard Biesheuvel
2015-12-07 12:34       ` Ard Biesheuvel
2015-12-07 15:37         ` Catalin Marinas
2015-11-16 11:23 ` [PATCH v3 6/7] arm64: map linear region as non-executable Ard Biesheuvel
2015-12-07 16:19   ` Catalin Marinas
2015-12-07 16:22     ` Ard Biesheuvel
2015-12-07 16:27       ` Catalin Marinas
2015-11-16 11:23 ` [PATCH v3 7/7] arm64: allow kernel Image to be loaded anywhere in physical memory Ard Biesheuvel
2015-12-07 15:30   ` Catalin Marinas
2015-12-07 15:40     ` Ard Biesheuvel
2015-12-07 16:43       ` Catalin Marinas

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=20151203121840.GB28731@leverpostej \
    --to=mark.rutland@arm.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