Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1593367 > unrolled thread

[PATCHv4 00/33] 5-level paging

Back to article view | Back to linux.kernel

Contents

  [PATCHv4 00/33] 5-level paging "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> - 2017-03-06 15:10 +0100
    [PATCHv4 01/33] x86/cpufeature: Add 5-level paging detection "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> - 2017-03-06 15:10 +0100
    [PATCHv4 14/33] x86/kexec: support p4d_t "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> - 2017-03-06 15:10 +0100
    [PATCHv4 18/33] x86/xen: convert __xen_pgd_walk() and xen_cleanmfnmap() to support p4d "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> - 2017-03-06 15:10 +0100
      Re: [PATCHv4 18/33] x86/xen: convert __xen_pgd_walk() and  xen_cleanmfnmap() to support p4d Boris Ostrovsky <boris.ostrovsky@oracle.com> - 2017-03-06 21:50 +0100
        Re: [PATCHv4 18/33] x86/xen: convert __xen_pgd_walk() and  xen_cleanmfnmap() to support p4d "Kirill A. Shutemov" <kirill@shutemov.name> - 2017-03-07 14:10 +0100
          Re: [PATCHv4 18/33] x86/xen: convert __xen_pgd_walk() and  xen_cleanmfnmap() to support p4d Boris Ostrovsky <boris.ostrovsky@oracle.com> - 2017-03-07 19:20 +0100
            Re: [Xen-devel] [PATCHv4 18/33] x86/xen: convert __xen_pgd_walk() and  xen_cleanmfnmap() to support p4d Andrew Cooper <andrew.cooper3@citrix.com> - 2017-03-07 19:30 +0100
              Re: [Xen-devel] [PATCHv4 18/33] x86/xen: convert __xen_pgd_walk() and  xen_cleanmfnmap() to support p4d Boris Ostrovsky <boris.ostrovsky@oracle.com> - 2017-03-07 20:30 +0100
    [PATCHv4 30/33] x86/mm: make kernel_physical_mapping_init() support 5-level paging "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> - 2017-03-06 15:10 +0100
    [PATCHv4 21/33] x86/asm: remove __VIRTUAL_MASK_SHIFT==47 assert "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> - 2017-03-06 15:10 +0100
    [PATCHv4 08/33] x86: basic changes into headers for 5-level paging "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> - 2017-03-06 15:10 +0100
    [PATCHv4 16/33] x86/mm/pat: handle additional page table "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> - 2017-03-06 15:10 +0100
    [PATCHv4 05/33] asm-generic: introduce <asm-generic/pgtable-nop4d.h> "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> - 2017-03-06 15:10 +0100
    [PATCHv4 15/33] x86/efi: handle p4d in EFI pagetables "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> - 2017-03-06 15:10 +0100
    [PATCHv4 19/33] x86: convert the rest of the code to support p4d_t "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> - 2017-03-06 15:10 +0100
    [PATCHv4 20/33] x86: detect 5-level paging support "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> - 2017-03-06 15:10 +0100
    [PATCHv4 07/33] mm: introduce __p4d_alloc() "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> - 2017-03-06 15:10 +0100
    [PATCHv4 27/33] x86/espfix: support 5-level paging "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> - 2017-03-06 15:10 +0100
    [PATCHv4 13/33] x86/power: support p4d_t in hibernate code "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> - 2017-03-06 15:10 +0100
    [PATCHv4 02/33] asm-generic: introduce 5level-fixup.h "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> - 2017-03-06 15:20 +0100
    Re: [PATCHv4 00/33] 5-level paging Linus Torvalds <torvalds@linux-foundation.org> - 2017-03-06 19:40 +0100
      Re: [PATCHv4 00/33] 5-level paging Thomas Gleixner <tglx@linutronix.de> - 2017-03-06 19:50 +0100
        Re: [PATCHv4 00/33] 5-level paging Linus Torvalds <torvalds@linux-foundation.org> - 2017-03-06 20:10 +0100
          Re: [PATCHv4 00/33] 5-level paging "Kirill A. Shutemov" <kirill@shutemov.name> - 2017-03-06 20:10 +0100
            Re: [PATCHv4 00/33] 5-level paging Linus Torvalds <torvalds@linux-foundation.org> - 2017-03-06 20:50 +0100
        Re: [PATCHv4 00/33] 5-level paging Stephen Rothwell <sfr@canb.auug.org.au> - 2017-03-07 02:30 +0100
          Re: [PATCHv4 00/33] 5-level paging Thomas Gleixner <tglx@linutronix.de> - 2017-03-07 11:20 +0100

Page 2 of 2 — ← Prev page 1 [2]

#1593395 — [PATCHv4 02/33] asm-generic: introduce 5level-fixup.h

We are going to switch core MM to 5-level paging abstraction.

This is preparation step which adds <asm-generic/5level-fixup.h>
As with 4level-fixup.h, the new header allows quickly make all
architectures compatible with 5-level paging in core MM.

In long run we would like to switch architectures to properly folded p4d
level by using <asm-generic/pgtable-nop4d.h>, but it requires more
changes to arch-specific code.

Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
---
 include/asm-generic/4level-fixup.h |  3 ++-
 include/asm-generic/5level-fixup.h | 41 ++++++++++++++++++++++++++++++++++++++
 include/linux/mm.h                 |  3 +++
 3 files changed, 46 insertions(+), 1 deletion(-)
 create mode 100644 include/asm-generic/5level-fixup.h

diff --git a/include/asm-generic/4level-fixup.h b/include/asm-generic/4level-fixup.h
index 5bdab6bffd23..928fd66b1271 100644
--- a/include/asm-generic/4level-fixup.h
+++ b/include/asm-generic/4level-fixup.h
@@ -15,7 +15,6 @@
 	((unlikely(pgd_none(*(pud))) && __pmd_alloc(mm, pud, address))? \
  		NULL: pmd_offset(pud, address))
 
-#define pud_alloc(mm, pgd, address)	(pgd)
 #define pud_offset(pgd, start)		(pgd)
 #define pud_none(pud)			0
 #define pud_bad(pud)			0
@@ -35,4 +34,6 @@
 #undef  pud_addr_end
 #define pud_addr_end(addr, end)		(end)
 
+#include <asm-generic/5level-fixup.h>
+
 #endif
diff --git a/include/asm-generic/5level-fixup.h b/include/asm-generic/5level-fixup.h
new file mode 100644
index 000000000000..b5ca82dc4175
--- /dev/null
+++ b/include/asm-generic/5level-fixup.h
@@ -0,0 +1,41 @@
+#ifndef _5LEVEL_FIXUP_H
+#define _5LEVEL_FIXUP_H
+
+#define __ARCH_HAS_5LEVEL_HACK
+#define __PAGETABLE_P4D_FOLDED
+
+#define P4D_SHIFT			PGDIR_SHIFT
+#define P4D_SIZE			PGDIR_SIZE
+#define P4D_MASK			PGDIR_MASK
+#define PTRS_PER_P4D			1
+
+#define p4d_t				pgd_t
+
+#define pud_alloc(mm, p4d, address) \
+	((unlikely(pgd_none(*(p4d))) && __pud_alloc(mm, p4d, address)) ? \
+		NULL : pud_offset(p4d, address))
+
+#define p4d_alloc(mm, pgd, address)	(pgd)
+#define p4d_offset(pgd, start)		(pgd)
+#define p4d_none(p4d)			0
+#define p4d_bad(p4d)			0
+#define p4d_present(p4d)		1
+#define p4d_ERROR(p4d)			do { } while (0)
+#define p4d_clear(p4d)			pgd_clear(p4d)
+#define p4d_val(p4d)			pgd_val(p4d)
+#define p4d_populate(mm, p4d, pud)	pgd_populate(mm, p4d, pud)
+#define p4d_page(p4d)			pgd_page(p4d)
+#define p4d_page_vaddr(p4d)		pgd_page_vaddr(p4d)
+
+#define __p4d(x)			__pgd(x)
+#define set_p4d(p4dp, p4d)		set_pgd(p4dp, p4d)
+
+#undef p4d_free_tlb
+#define p4d_free_tlb(tlb, x, addr)	do { } while (0)
+#define p4d_free(mm, x)			do { } while (0)
+#define __p4d_free_tlb(tlb, x, addr)	do { } while (0)
+
+#undef  p4d_addr_end
+#define p4d_addr_end(addr, end)		(end)
+
+#endif
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 0d65dd72c0f4..be1fe264eb37 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1619,11 +1619,14 @@ int __pte_alloc_kernel(pmd_t *pmd, unsigned long address);
  * Remove it when 4level-fixup.h has been removed.
  */
 #if defined(CONFIG_MMU) && !defined(__ARCH_HAS_4LEVEL_HACK)
+
+#ifndef __ARCH_HAS_5LEVEL_HACK
 static inline pud_t *pud_alloc(struct mm_struct *mm, pgd_t *pgd, unsigned long address)
 {
 	return (unlikely(pgd_none(*pgd)) && __pud_alloc(mm, pgd, address))?
 		NULL: pud_offset(pgd, address);
 }
+#endif /* !__ARCH_HAS_5LEVEL_HACK */
 
 static inline pmd_t *pmd_alloc(struct mm_struct *mm, pud_t *pud, unsigned long address)
 {
-- 
2.11.0

[toc] | [prev] | [next] | [standalone]

#1593577

On Mon, Mar 6, 2017 at 5:53 AM, Kirill A. Shutemov
<kirill.shutemov@linux.intel.com> wrote:
> Here is v4 of 5-level paging patchset. Please review and consider applying.

I think we should just aim for this being in 4.12. I don't see any
real reason to delay merging it, the main question in my mind is which
tree it would go through. A separate x86 -tip branch, or Andrew's mm
tree or me just pulling directly, or what?

I basically think it's in good enough shape that future work might as
well be based on this being merged. No?

                   Linus

[toc] | [prev] | [next] | [standalone]

#1593592

On Mon, 6 Mar 2017, Linus Torvalds wrote:

> On Mon, Mar 6, 2017 at 5:53 AM, Kirill A. Shutemov
> <kirill.shutemov@linux.intel.com> wrote:
> > Here is v4 of 5-level paging patchset. Please review and consider applying.
> 
> I think we should just aim for this being in 4.12. I don't see any
> real reason to delay merging it, the main question in my mind is which
> tree it would go through. A separate x86 -tip branch, or Andrew's mm
> tree or me just pulling directly, or what?

We can take it through -tip and I prefer to do so as there are other
changes in the page table code lurking.

We probably need to split it apart:

   - Apply the mm core only parts to a branch which can be pulled into
     Andrews mm-tree

   - Base the x86 changes on top of it

So both worlds can work on top of the mm core parts (almost
independently). From what I have seen so far, it's more likely that we get
delta changes/fixes on the x86 side than on the mm core side. And if we get
changes on the mm core side, we can deal with that via the seperate mm core
branch.

Andrew, does that work for you?

Thanks,

	tglx

[toc] | [prev] | [next] | [standalone]

#1593607

On Mon, Mar 6, 2017 at 10:42 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
>
> We probably need to split it apart:
>
>    - Apply the mm core only parts to a branch which can be pulled into
>      Andrews mm-tree
>
>    - Base the x86 changes on top of it

I'll happily take some of the preparatory patches for 4.11 too. Some
of them just don't seem to have any downside. The cpuid stuff, and the
basic scaffolding we could easily merge early. That includes the dummy
5level code, ie "5level-fixup.h" and even some of the mm side that
doesn't actually change anything and just prepares for the real code.

But having some base branch too just for avoiding conflicts with
whatever mm stuff that Andrew keeps around sounds fine too.

                   Linus

[toc] | [prev] | [next] | [standalone]

#1593609

On Mon, Mar 06, 2017 at 11:03:56AM -0800, Linus Torvalds wrote:
> On Mon, Mar 6, 2017 at 10:42 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
> >
> > We probably need to split it apart:
> >
> >    - Apply the mm core only parts to a branch which can be pulled into
> >      Andrews mm-tree
> >
> >    - Base the x86 changes on top of it
> 
> I'll happily take some of the preparatory patches for 4.11 too. Some
> of them just don't seem to have any downside. The cpuid stuff, and the
> basic scaffolding we could easily merge early. That includes the dummy
> 5level code, ie "5level-fixup.h" and even some of the mm side that
> doesn't actually change anything and just prepares for the real code.

The first 7 patches are relatively low-risk. It would be nice to have them
in earlier.

I'm commited to address any possible drawbacks quickly if you considering
applying it into v4.11.

-- 
 Kirill A. Shutemov

[toc] | [prev] | [next] | [standalone]

#1593669

On Mon, Mar 6, 2017 at 11:09 AM, Kirill A. Shutemov
<kirill@shutemov.name> wrote:
>
> The first 7 patches are relatively low-risk. It would be nice to have them
> in earlier.

Ok, I gave those another look since you mentioned them in particular,
and they still look fine and non-controversial to me. I'd be willing
to take them directly, and into 4.11, to make future integration
eastier and avoid conflicts with other mm code during the 4.12 merge
window.

Just looking at my own inbox, I would suggest that maybe you should
send that small early series as a separate patch series, because those
patches actually got mixed up in my inbox with all the other patches
in the series. Email sending in quick succession does not tend to keep
things ordered. I suspect that happened to others too.

We might have people who are *not* willing to look at the whole
33-patch series that has a lot of x86 code in it, but are willing to
look through the first 7 emails when they are clearly separated out..

                  Linus

[toc] | [prev] | [next] | [standalone]

#1593843

Hi Thomas,

On Mon, 6 Mar 2017 19:42:05 +0100 (CET) Thomas Gleixner <tglx@linutronix.de> wrote:
>
> We probably need to split it apart:
> 
>    - Apply the mm core only parts to a branch which can be pulled into
>      Andrews mm-tree

Andrew's mm-tree is not a git tree it is a quilt series ...

-- 
Cheers,
Stephen Rothwell

[toc] | [prev] | [next] | [standalone]

#1594076

On Tue, 7 Mar 2017, Stephen Rothwell wrote:
> Hi Thomas,
> 
> On Mon, 6 Mar 2017 19:42:05 +0100 (CET) Thomas Gleixner <tglx@linutronix.de> wrote:
> >
> > We probably need to split it apart:
> > 
> >    - Apply the mm core only parts to a branch which can be pulled into
> >      Andrews mm-tree
> 
> Andrew's mm-tree is not a git tree it is a quilt series ...

I know, but creating a 'mm-base-5-level.patch' from a git branch is trivial
enough.

Thanks,

	tglx

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.kernel

csiph-web