All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.