From: santosh.shilimkar@ti.com (Santosh Shilimkar)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 5/6] ARM: mm: Recreate kernel mappings in early_paging_init()
Date: Fri, 4 Oct 2013 12:12:36 -0400 [thread overview]
Message-ID: <524EE8F4.4060407@ti.com> (raw)
In-Reply-To: <20131004155958.GU24303@mudshark.cambridge.arm.com>
On Friday 04 October 2013 11:59 AM, Will Deacon wrote:
> On Thu, Oct 03, 2013 at 10:17:59PM +0100, Santosh Shilimkar wrote:
>> This patch adds a step in the init sequence, in order to recreate
>> the kernel code/data page table mappings prior to full paging
>> initialization. This is necessary on LPAE systems that run out of
>> a physical address space outside the 4G limit. On these systems,
>> this implementation provides a machine descriptor hook that allows
>> the PHYS_OFFSET to be overridden in a machine specific fashion.
>
> [...]
>
>> diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
>> index b1d17ee..47c7497 100644
>> --- a/arch/arm/mm/mmu.c
>> +++ b/arch/arm/mm/mmu.c
>> @@ -28,6 +28,7 @@
>> #include <asm/highmem.h>
>> #include <asm/system_info.h>
>> #include <asm/traps.h>
>> +#include <asm/procinfo.h>
>>
>> #include <asm/mach/arch.h>
>> #include <asm/mach/map.h>
>> @@ -1315,6 +1316,87 @@ static void __init map_lowmem(void)
>> }
>> }
>>
>> +#ifdef CONFIG_ARM_LPAE
>> +extern void fixup_pv_table(const void *, unsigned long);
>> +extern const void *__pv_table_begin, *__pv_table_end;
>> +
>> +/*
>> + * early_paging_init() recreates boot time page table setup, allowing machines
>> + * to switch over to a high (>4G) address space on LPAE systems
>> + */
>> +void __init early_paging_init(const struct machine_desc *mdesc,
>> + struct proc_info_list *procinfo)
>> +{
>> + pmdval_t pmdprot = procinfo->__cpu_mm_mmu_flags;
>> + unsigned long map_start, map_end;
>> + pgd_t *pgd0, *pgdk;
>> + pud_t *pud0, *pudk;
>> + pmd_t *pmd0, *pmdk;
>> + phys_addr_t phys;
>> + int i;
>> +
>> + /* remap kernel code and data */
>> + map_start = init_mm.start_code;
>> + map_end = init_mm.brk;
>> +
>> + /* get a handle on things... */
>> + pgd0 = pgd_offset_k(0);
>> + pud0 = pud_offset(pgd0, 0);
>> + pmd0 = pmd_offset(pud0, 0);
>> +
>> + pgdk = pgd_offset_k(map_start);
>> + pudk = pud_offset(pgdk, map_start);
>> + pmdk = pmd_offset(pudk, map_start);
>> +
>> + phys = PHYS_OFFSET;
>> +
>> + if (mdesc->init_meminfo) {
>> + mdesc->init_meminfo();
>> + /* Run the patch stub to update the constants */
>> + fixup_pv_table(&__pv_table_begin,
>> + (&__pv_table_end - &__pv_table_begin) << 2);
>> +
>> + /*
>> + * Cache cleaning operations for self-modifying code
>> + * We should clean the entries by MVA but running a
>> + * for loop over every pv_table entry pointer would
>> + * just complicate the code.
>> + */
>> + flush_cache_louis();
>> + dsb();
>> + isb();
>
> You don't need either of these barriers.
>
Agree. Just want to be clear, its because they are already present
in flush_cache_louis(), right ?
>> + }
>> +
>> + /* remap level 1 table */
>> + for (i = 0; i < PTRS_PER_PGD; i++) {
>> + *pud0++ = __pud(__pa(pmd0) | PMD_TYPE_TABLE | L_PGD_SWAPPER);
>> + pmd0 += PTRS_PER_PMD;
>> + }
>> +
>> + /* remap pmds for kernel mapping */
>> + phys = __pa(map_start) & PMD_MASK;
>> + do {
>> + *pmdk++ = __pmd(phys | pmdprot);
>> + phys += PMD_SIZE;
>> + } while (phys < map_end);
>> +
>> + flush_cache_all();
>
> Why are you being so heavyweight with your cacheflushing? If you're just
> interested in flushing the new page tables, then use the proper accessors to
> build them. The only case I think you need to flush the world is for VIVT,
> which you won't have with LPAE (you could have a BUG_ON here).
>
It was mainly to avoid all the looping MVA based stuff but you have valid point.
I shall look at it and see what can be done.
>> + cpu_set_ttbr(0, __pa(pgd0));
>> + cpu_set_ttbr(1, __pa(pgd0) + TTBR1_OFFSET);
>
> Can you not use cpu_switch_mm with the init_mm for this?
>
Probably yes. Will have a look at it.
Regards,
Santosh
next prev parent reply other threads:[~2013-10-04 16:12 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-03 21:17 [PATCH v3 0/6] ARM: mm: Extend the runtime patch stub for PAE systems Santosh Shilimkar
2013-10-03 21:17 ` [PATCH v3 1/6] ARM: mm: use phys_addr_t appropriately in p2v and v2p conversions Santosh Shilimkar
2013-10-03 21:17 ` [PATCH v3 2/6] ARM: mm: Introduce virt_to_idmap() with an arch hook Santosh Shilimkar
2013-10-03 21:17 ` [PATCH v3 3/6] ARM: mm: Move the idmap print to appropriate place in the code Santosh Shilimkar
2013-10-03 21:17 ` [PATCH v3 4/6] ARM: mm: Correct virt_to_phys patching for 64 bit physical addresses Santosh Shilimkar
2013-10-04 0:17 ` Nicolas Pitre
2013-10-04 5:37 ` Sricharan R
2013-10-04 13:02 ` Nicolas Pitre
2013-10-07 19:25 ` Santosh Shilimkar
2013-10-07 19:42 ` Nicolas Pitre
2013-10-08 11:43 ` Sricharan R
2013-10-03 21:17 ` [PATCH v3 5/6] ARM: mm: Recreate kernel mappings in early_paging_init() Santosh Shilimkar
2013-10-04 0:23 ` Nicolas Pitre
2013-10-04 15:59 ` Will Deacon
2013-10-04 16:12 ` Santosh Shilimkar [this message]
2013-10-07 19:34 ` Santosh Shilimkar
2013-10-08 10:26 ` Will Deacon
2013-10-08 17:45 ` Santosh Shilimkar
2013-10-09 10:06 ` Will Deacon
2013-10-09 18:51 ` Santosh Shilimkar
2013-10-03 21:18 ` [PATCH v3 6/6] ARM: mm: Change the order of TLB/cache maintenance operations Santosh Shilimkar
2013-10-04 0:25 ` Nicolas Pitre
2013-10-04 8:46 ` Russell King - ARM Linux
2013-10-04 13:14 ` Nicolas Pitre
2013-10-04 13:19 ` Santosh Shilimkar
2013-10-04 15:52 ` Will Deacon
2013-10-04 16:03 ` Santosh Shilimkar
2013-10-09 18:56 ` Santosh Shilimkar
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=524EE8F4.4060407@ti.com \
--to=santosh.shilimkar@ti.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).