Linux support for ARM LPAE

Hi Russell,

If there are no further comments, could you please pull the ARM LPAE branch below? They should be merged after Will's idmap patches (no real conflict, just correctly functioning setup_mm_for_reboot).

Thanks.

The following changes since commit 5611cc4572e889b62a7b4c72a413536bf6a9c416:

Linux 3.2-rc4 (2011-12-01 14:56:01 -0800)

are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux.git for-next

Catalin Marinas (12):
ARM: pgtable: Fix compiler warning in ioremap.c introduced by nopud
ARM: LPAE: Move page table maintenance macros to pgtable-2level.h
ARM: LPAE: Move the FSR definitions to separate files
ARM: LPAE: Factor out classic-MMU specific code into proc-v7-2level.S
ARM: LPAE: Introduce the 3-level page table format definitions
ARM: LPAE: Page table maintenance for the 3-level format
ARM: LPAE: MMU setup for the 3-level page table format
ARM: LPAE: Invalidate the TLB before freeing the PMD
ARM: LPAE: Add fault handling support
ARM: LPAE: Add context switching support
ARM: LPAE: Add identity mapping support for the 3-level page table format
ARM: LPAE: Add the Kconfig entries

Russell King (1):
ARM: pgtable: switch to use pgtable-nopud.h

Will Deacon (2):
ARM: LPAE: add ISBs around MMU enabling code
ARM: LPAE: mark memory banks with start > ULONG_MAX as highmem

 arch/arm/Kconfig                            |    2 +-
 arch/arm/boot/compressed/head.S             |    1 +
 arch/arm/include/asm/assembler.h            |   11 ++
 arch/arm/include/asm/page.h                 |    4 +
 arch/arm/include/asm/pgalloc.h              |   26 ++++-
 arch/arm/include/asm/pgtable-2level.h       |   41 ++++++
 arch/arm/include/asm/pgtable-3level-hwdef.h |   77 ++++++++++++
 arch/arm/include/asm/pgtable-3level-types.h |   70 +++++++++++
 arch/arm/include/asm/pgtable-3level.h       |  155 +++++++++++++++++++++++
 arch/arm/include/asm/pgtable-hwdef.h        |    4 +
 arch/arm/include/asm/pgtable.h              |   43 +------
 arch/arm/include/asm/proc-fns.h             |   21 +++
 arch/arm/include/asm/system.h               |    8 ++
 arch/arm/include/asm/tlb.h                  |   12 ++-
 arch/arm/kernel/head.S                      |   47 +++++++-
 arch/arm/kernel/hw_breakpoint.c             |    8 +-
 arch/arm/kernel/sleep.S                     |    2 +
 arch/arm/mm/Kconfig                         |   17 +++
 arch/arm/mm/alignment.c                     |    2 +-
 arch/arm/mm/context.c                       |   19 +++-
 arch/arm/mm/fault.c                         |  111 +++--------------
 arch/arm/mm/fault.h                         |   27 ++++-
 arch/arm/mm/fsr-2level.c                    |   78 ++++++++++++
 arch/arm/mm/fsr-3level.c                    |   68 ++++++++++
 arch/arm/mm/idmap.c                         |   34 +++++-
 arch/arm/mm/ioremap.c                       |   39 ++++---
 arch/arm/mm/mmu.c                           |   46 +++++++-
 arch/arm/mm/pgd.c                           |   51 +++++++-
 arch/arm/mm/proc-macros.S                   |    5 +-
 arch/arm/mm/proc-v7-2level.S                |  171 ++++++++++++++++++++++++++
 arch/arm/mm/proc-v7-3level.S                |  150 +++++++++++++++++++++++
 arch/arm/mm/proc-v7.S                       |  177 +++------------------------
 32 files changed, 1204 insertions(+), 323 deletions(-)
 create mode 100644 arch/arm/include/asm/pgtable-3level-hwdef.h
 create mode 100644 arch/arm/include/asm/pgtable-3level-types.h
 create mode 100644 arch/arm/include/asm/pgtable-3level.h
 create mode 100644 arch/arm/mm/fsr-2level.c
 create mode 100644 arch/arm/mm/fsr-3level.c
 create mode 100644 arch/arm/mm/proc-v7-2level.S
 create mode 100644 arch/arm/mm/proc-v7-3level.S

Err, your tree contains a serious error.

tree bb5f2f68dd26a97343d255bb0b66f327cece91a5
parent b4521e369180054ddaacecbe83eadac8878f3501
author Russell King <[email protected]> 1321983028 +0000 committer Catalin Marinas <[email protected]> 1322842272 +0000

ARM: pgtable: switch to use pgtable-nopud.h

Nick Piggin noted upon introducing 4level-fixup.h:

| Add a temporary "fallback" header so architectures can run with
| the 4level pagetables patch without modification. All architectures
| should be converted to use the folding headers (include/asm-generic/
| pgtable-nop?d.h) as soon as possible, and the fallback header removed.

This makes ARM compliant with this statement.

If you commit a patch into a git tree, _you_ are supposed to _always_ add your own sign-off line to it unless it's already there.

Because of this, I'm going to _have_ to throw out the merge of this from the devel-stable branch (sorry folks) because it's not compliant with the DCO standards required.

I would say minor error but I agree, it needs fixing. This patch wasn't originally part of my LPAE series as I hoped you would have merged it during the last cycle. Now it had to be part of the pull request as LPAE patches depend on it.

Anyway, I'll fix this and send you another pull request. Unless you already merged your nopud patch in the devel-stable branch and I can rebase LPAE on top, just let me know which one you'd prefer (and a commit id if the latter).

Thanks.

Catalin

P.S. I say it's minor because it has the committer information. If you
     would pull someone else's branch which results in a fast-forward,
     you can't really tell whether it was a merge or cherry-pick, so the
     rule is not entirely consistent (unless you also mandate --no-ff
     for merges).

The DCO is a viewed by many as having legal implications. Not doing it means - in this case - that you do not believe you have the right to pass the change on. In that case, I can't accept it from you.

If you don't understand that, please, go read Documentation/SubmittingPatches to learn about when you are required to sign off on patches before committing them.

I've stated many times why it's not merged, and for the N'th time: it generates warnings. I'm _not_ merging something that is known to add warnings such as those which this patch produces without there being a fix for it. You know that _very well_ because I've said it several times, not only by email but also on our various phone calls.

I've dealt with this patch in exactly the same way at every merge window we've had for the last _year_ - I've queued it up with the expectation that hopefully someone would fix the warnings, the warnings didn't get fixed, so it got dropped from the pull request. Immediately after the merge window (which includes this) it gets reinstated back into linux-next.

That is a known and accepted "limitation" - as is the "limitation" that you can't add the sign-off to each commit you've pulled in. What Linus really wants is stuff to be tracked to the point it enters into git via sign-offs. From then on, the accountability trail follows the merge commits.

Yes, I'm fully aware, and I sent you a fix-up in the past. I can re-write that fix-up in a few other ways if you don't like the current one, just let me know.

Catalin

OK, I took the time to implement another RFC fix-up for this. It's only compile-tested at the moment and may need a few more tweaks but it gives you an idea on what it tries to achieve. With the classic MMU, all the pud_alloc/pmd_alloc just translate to pud_offset/pmd_offset so the current behaviour should not be affected. In theory, it could work with LPAE as well as it allocates the pmd at run-time (we don't really need freeing them during unmap). Any thoughts?

ARM: pgtable: Fix compiler warning in ioremap.c introduced by nopud

From: Catalin Marinas <[email protected]>

With the arch/arm code conversion to pgtable-nopud.h, the section and supersection (un|re)map code triggers compiler warnings on UP systems. This is caused by pmd_offset() being given a pgd_t argument rather than a pud_t one. This patch makes the necessary conversion via pud_alloc() and pmd_alloc().

---
 arch/arm/mm/ioremap.c |   50 ++++++++++++++++++++++++++++++++-----------------
 1 files changed, 33 insertions(+), 17 deletions(-)

index bdb248c..4827851 100644
@@ -78,13 +78,20 @@ void __check_kvm_seq(struct mm_struct *mm)
 static void unmap_area_sections(unsigned long virt, unsigned long size)
 {
 	unsigned long addr = virt, end = virt + (size & ~(SZ_1M - 1));
-	pgd_t *pgd;
 
 	flush_cache_vunmap(addr, end);
-	pgd = pgd_offset_k(addr);
 	do {
-		pmd_t pmd, *pmdp = pmd_offset(pgd, addr);
+		pgd_t *pgd = pgd_offset_k(addr);
+		pud_t *pud;
+		pmd_t pmd, *pmdp;
 
+		if (pgd_none(*pgd))
+			continue;
+		pud = pud_offset(pgd, addr);
+		if (pud_none(*pud))
+			continue;
+
+		pmdp = pmd_offset(pud, addr);
 		pmd = *pmdp;
 		if (!pmd_none(pmd)) {
 			/*

@@ -103,10 +110,7 @@ static void unmap_area_sections(unsigned long virt, unsigned long size)
 			if ((pmd_val(pmd) & PMD_TYPE_MASK) == PMD_TYPE_TABLE)
 				pte_free_kernel(&init_mm, pmd_page_vaddr(pmd));
 		}
-
-		addr += PGDIR_SIZE;
-		pgd++;
-	} while (addr < end);
+	} while (addr += PMD_SIZE, addr < end);
 
 	/*
 	 * Ensure that the active_mm is up to date - we want to

@@ -123,7 +127,6 @@ remap_area_sections(unsigned long virt, unsigned long pfn,
 		    size_t size, const struct mem_type *type)
 {
 	unsigned long addr = virt, end = virt + size;
-	pgd_t *pgd;
 
 	/*
 	 * Remove and free any PTE-based mapping, and

@@ -131,9 +134,17 @@ remap_area_sections(unsigned long virt, unsigned long pfn,
 	 */
 	unmap_area_sections(virt, size);
 
-	pgd = pgd_offset_k(addr);
 	do {
-		pmd_t *pmd = pmd_offset(pgd, addr);
+		pgd_t *pgd = pgd_offset_k(addr);
+		pud_t *pud;
+		pmd_t *pmd;
+
+		pud = pud_alloc(&init_mm, pgd, addr);
+		if (!pud)
+			return -ENOMEM;
+		pmd = pmd_alloc(&init_mm, pud, addr);
+		if (!pmd)
+			return -ENOMEM;
 
 		pmd[0] = __pmd(__pfn_to_phys(pfn) | type->prot_sect);
 		pfn += SZ_1M >> PAGE_SHIFT;

@@ -141,8 +152,7 @@ remap_area_sections(unsigned long virt, unsigned long pfn,
 		pfn += SZ_1M >> PAGE_SHIFT;
 		flush_pmd_entry(pmd);
 
-		addr += PGDIR_SIZE;
-		pgd++;
+		addr += PMD_SIZE;
 	} while (addr < end);
 
 	return 0;

@@ -153,7 +163,6 @@ remap_area_supersections(unsigned long virt, unsigned long pfn,
 			 size_t size, const struct mem_type *type)
 {
 	unsigned long addr = virt, end = virt + size;
-	pgd_t *pgd;
 
 	/*
 	 * Remove and free any PTE-based mapping, and

@@ -161,23 +170,30 @@ remap_area_supersections(unsigned long virt, unsigned long pfn,
 	 */
 	unmap_area_sections(virt, size);
 
-	pgd = pgd_offset_k(virt);
 	do {
+		pgd_t *pgd = pgd_offset_k(addr);
+		pud_t *pud;
 		unsigned long super_pmd_val, i;
 
+		pud = pud_alloc(&init_mm, pgd, addr);
+		if (!pud)
+			return -ENOMEM;
 		super_pmd_val = __pfn_to_phys(pfn) | type->prot_sect |
 				PMD_SECT_SUPER;
 		super_pmd_val |= ((pfn >> (32 - PAGE_SHIFT)) & 0xf) << 20;
 
 		for (i = 0; i < 8; i++) {
-			pmd_t *pmd = pmd_offset(pgd, addr);
+			pmd_t *pmd;
+
+			pmd = pmd_alloc(&init_mm, pud, addr);
+			if (!pmd)
+				return -ENOMEM;
 
 			pmd[0] = __pmd(super_pmd_val);
 			pmd[1] = __pmd(super_pmd_val);
 			flush_pmd_entry(pmd);
 
-			addr += PGDIR_SIZE;
-			pgd++;
+			addr += PMD_SIZE;
 		}
 
 		pfn += SUPERSECTION_SIZE >> PAGE_SHIFT;

Catalin

So, do I now take this email as you saying that _your_ LPAE tree is not ready for merging because you want to rework this patch, or what?

Because you've decided to go down the path of reworking this patch, I consider it dangerous for me to just pull from your tree again - I've no idea what I'd get, and I've no idea whether what's there is what you want me to merge.

So, this is causing extra delay, and there's nothing _I_ can do about it at my end.

This is getting completely out of hand.

What I want from you - by 5pm tomorrow so I can get this stuff merged - is a pull request for the LPAE stuff as it was in your v2 pull request, either based on top of _either_ my devel-stable (if you can get it - as the machine is having severe problems running git atm) or with Will's idmap changes merged into it _before_ the LPAE changes.

I suspect you'll have to do the latter though, because I don't think I can sort out git on the server at the moment.

No, I'm not, it's you saying that your nopud patch does not have any fix for the warnings, even though I had fixes posted for months. The same fix that's in my LPAE series was sent to you to include with your patch but instead you kept saying (even twice in the past week) that those warning had no fix. From that, I understand that you really don't consider my patch a proper fix for the compiler warnings.

I haven't changed anything in my LPAE branch, just posted an alternative fix-up for the nopud patch. Please _state_ clearly whether you consider my original (in the LPAE series) fixup valid or not. If yes, I'm happy that I don't have to rework anything.

Yes, that's fine with me, I already talked to Will about this earlier today but wanted to get your reply first.

Catalin

Stop it Catalin. You're being utterly rediculous. You asked why I hadn't merged my patch during the last merge window. So I told you - just like I've been telling you by email and during our monthly calls why I've not been merging it. You asked the question (again) so I told you why (again).

Utter rubbish. I'll say it again. You asked why I hadn't merged my patch. So I told you - just like I've been telling you by email and during our monthly calls why I've not been merging it. You asked the question (again) so I told you why.

WTF.

Oh for god sake. I think I've already stated very clearly what I want. I see no reason to repeat myself yet again.

For the avoidance of any doubt - and any argument - the 5pm time limit is there to bring this debacle to a close in a reasonable period. It's purely there because I want to get this merged by end of Thursday and no later.

To summarise, my objections are quite simply:

1. Your lack of sign-off on my patch which you merged (which you've addressed in pull v2.)
2. The combined point of the merge conflict between your tree and Will's idmap tree, plus the dependency your tree _does_ have on the idmap changes means it _should_ include Will's idmap changes to ensure bisectability - and this has the side effect of solving the merge conflict which shouldn't be there.

Any other objections which you think I've made are a purely a figment of your imagination.

Now, one thing I haven't checked is the ordering of the commits - particularly the ordering of the 'fix' patch and my patch. Unfortunately, standard git pull messages don't give the order so it's not something I can readily check. I commented on this issue when you posted the patch set. I hope it will be correct for pull v3 (iow, the fix patch first, then my patch.)

So you mean you're submitting me my patch that I've been avoiding merging into mainline _without_ the fixup patch? It seems not - you do have it in your pull request:

ARM: pgtable: Fix compiler warning in ioremap.c introduced by nopud

So what's the issue? Why do you want to rewrite it yet again?

My guess is that you haven't actually READ what I said above (which is quoted). And what is quoted above is _me_ explaining _why_ I have not merged my own patch and why _I_ _consider_ _the_ _patch_ _as_ _it_ _stands_ _to_ _not_ _be_ _immediately_ _suitable_ _for_ _merging_ ___on___ ___its___ ___own___.

The fact is, with the "fix" patch, it _does_ become suitable for merging.

Are you getting the message yet?

Provided you've fixed the sign-off (which you say you have) the only remaining problem is the conflict between your tree and Will's tree which you actually require for LPAE to be buildable. Which, I'll point out, I'm not looking at at the moment because I'm writing this email to you this evening instead.