From: Arnd Bergmann <arnd@arndb.de>
To: Ingo Molnar <mingo@kernel.org>
Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Andrew Morton <akpm@linux-foundation.org>,
x86@kernel.org, Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
Andi Kleen <ak@linux.intel.com>,
Dave Hansen <dave.hansen@intel.com>,
Andy Lutomirski <luto@amacapital.net>,
linux-arch@vger.kernel.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
maxim.kuvyrkov@linaro.org,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will.deacon@arm.com>,
broonie@kernel.org, schwidefsky@de.ibm.com
Subject: Re: [RFC, PATCHv1 00/28] 5-level paging
Date: Fri, 09 Dec 2016 11:24:12 +0100 [thread overview]
Message-ID: <13962749.Q2mLWEctkQ@wuerfel> (raw)
In-Reply-To: <20161209050130.GC2595@gmail.com>
On Friday, December 9, 2016 6:01:30 AM CET Ingo Molnar wrote:
> > - Handle opt-in wider address space for userspace.
> >
> > Not all userspace is ready to handle addresses wider than current
> > 47-bits. At least some JIT compiler make use of upper bits to encode
> > their info.
> >
> > We need to have an interface to opt-in wider addresses from userspace
> > to avoid regressions.
> >
> > For now, I've included testing-only patch which bumps TASK_SIZE to
> > 56-bits. This can be handy for testing to see what breaks if we max-out
> > size of virtual address space.
>
> So this is just a detail - but it sounds a bit limiting to me to provide an 'opt
> in' flag for something that will work just fine on the vast majority of 64-bit
> software.
>
> Please make this an opt out compatibility flag instead: similar to how we handle
> address space layout limitations/quirks ABI details, such as ADDR_LIMIT_32BIT,
> ADDR_LIMIT_3GB, ADDR_COMPAT_LAYOUT, READ_IMPLIES_EXEC, etc.
We've had a similar discussion about JIT software on ARM64, which has a wide
range of supported page table layouts and some software wants to limit that
to a specific number.
I don't remember the outcome of that discussion, but I'm adding a few people
to Cc that might remember.
There have also been some discussions in the past to make the depth of the
page table a per-task decision on s390, since you may have some tasks that
run just fine with two or three levels of paging while another task actually
wants the full 64-bit address space. I wonder how much extra work this would
be on top of the boot-time option.
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC, PATCHv1 00/28] 5-level paging
Date: Fri, 09 Dec 2016 11:24:12 +0100 [thread overview]
Message-ID: <13962749.Q2mLWEctkQ@wuerfel> (raw)
In-Reply-To: <20161209050130.GC2595@gmail.com>
On Friday, December 9, 2016 6:01:30 AM CET Ingo Molnar wrote:
> > - Handle opt-in wider address space for userspace.
> >
> > Not all userspace is ready to handle addresses wider than current
> > 47-bits. At least some JIT compiler make use of upper bits to encode
> > their info.
> >
> > We need to have an interface to opt-in wider addresses from userspace
> > to avoid regressions.
> >
> > For now, I've included testing-only patch which bumps TASK_SIZE to
> > 56-bits. This can be handy for testing to see what breaks if we max-out
> > size of virtual address space.
>
> So this is just a detail - but it sounds a bit limiting to me to provide an 'opt
> in' flag for something that will work just fine on the vast majority of 64-bit
> software.
>
> Please make this an opt out compatibility flag instead: similar to how we handle
> address space layout limitations/quirks ABI details, such as ADDR_LIMIT_32BIT,
> ADDR_LIMIT_3GB, ADDR_COMPAT_LAYOUT, READ_IMPLIES_EXEC, etc.
We've had a similar discussion about JIT software on ARM64, which has a wide
range of supported page table layouts and some software wants to limit that
to a specific number.
I don't remember the outcome of that discussion, but I'm adding a few people
to Cc that might remember.
There have also been some discussions in the past to make the depth of the
page table a per-task decision on s390, since you may have some tasks that
run just fine with two or three levels of paging while another task actually
wants the full 64-bit address space. I wonder how much extra work this would
be on top of the boot-time option.
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: Ingo Molnar <mingo@kernel.org>
Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Andrew Morton <akpm@linux-foundation.org>,
x86@kernel.org, Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
Andi Kleen <ak@linux.intel.com>,
Dave Hansen <dave.hansen@intel.com>,
Andy Lutomirski <luto@amacapital.net>,
linux-arch@vger.kernel.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
maxim.kuvyrkov@linaro.org,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will.deacon@arm.com>,
broonie@kernel.org, schwidefsky@de.ibm.com
Subject: Re: [RFC, PATCHv1 00/28] 5-level paging
Date: Fri, 09 Dec 2016 11:24:12 +0100 [thread overview]
Message-ID: <13962749.Q2mLWEctkQ@wuerfel> (raw)
In-Reply-To: <20161209050130.GC2595@gmail.com>
On Friday, December 9, 2016 6:01:30 AM CET Ingo Molnar wrote:
> > - Handle opt-in wider address space for userspace.
> >
> > Not all userspace is ready to handle addresses wider than current
> > 47-bits. At least some JIT compiler make use of upper bits to encode
> > their info.
> >
> > We need to have an interface to opt-in wider addresses from userspace
> > to avoid regressions.
> >
> > For now, I've included testing-only patch which bumps TASK_SIZE to
> > 56-bits. This can be handy for testing to see what breaks if we max-out
> > size of virtual address space.
>
> So this is just a detail - but it sounds a bit limiting to me to provide an 'opt
> in' flag for something that will work just fine on the vast majority of 64-bit
> software.
>
> Please make this an opt out compatibility flag instead: similar to how we handle
> address space layout limitations/quirks ABI details, such as ADDR_LIMIT_32BIT,
> ADDR_LIMIT_3GB, ADDR_COMPAT_LAYOUT, READ_IMPLIES_EXEC, etc.
We've had a similar discussion about JIT software on ARM64, which has a wide
range of supported page table layouts and some software wants to limit that
to a specific number.
I don't remember the outcome of that discussion, but I'm adding a few people
to Cc that might remember.
There have also been some discussions in the past to make the depth of the
page table a per-task decision on s390, since you may have some tasks that
run just fine with two or three levels of paging while another task actually
wants the full 64-bit address space. I wonder how much extra work this would
be on top of the boot-time option.
Arnd
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2016-12-09 10:27 UTC|newest]
Thread overview: 129+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-08 16:21 [RFC, PATCHv1 00/28] 5-level paging Kirill A. Shutemov
2016-12-08 16:21 ` Kirill A. Shutemov
2016-12-08 16:21 ` [QEMU, PATCH] x86: implement la57 paging mode Kirill A. Shutemov
2016-12-08 16:21 ` [Qemu-devel] " Kirill A. Shutemov
2016-12-08 16:21 ` Kirill A. Shutemov
2016-12-08 16:48 ` [Qemu-devel] " no-reply
2016-12-08 16:48 ` no-reply
2016-12-08 16:48 ` no-reply
2016-12-08 16:48 ` no-reply
2016-12-08 16:21 ` [RFC, PATCHv1 01/28] asm-generic: introduce 5level-fixup.h Kirill A. Shutemov
2016-12-08 16:21 ` Kirill A. Shutemov
2016-12-08 16:21 ` [RFC, PATCHv1 02/28] asm-generic: introduce __ARCH_USE_5LEVEL_HACK Kirill A. Shutemov
2016-12-08 16:21 ` Kirill A. Shutemov
2016-12-08 16:21 ` [RFC, PATCHv1 03/28] arch, mm: convert all architectures to use 5level-fixup.h Kirill A. Shutemov
2016-12-08 16:21 ` Kirill A. Shutemov
2016-12-08 16:21 ` [RFC, PATCHv1 04/28] asm-generic: introduce <asm-generic/pgtable-nop4d.h> Kirill A. Shutemov
2016-12-08 16:21 ` Kirill A. Shutemov
2016-12-08 16:21 ` [RFC, PATCHv1 05/28] mm: convert generic code to 5-level paging Kirill A. Shutemov
2016-12-08 16:21 ` Kirill A. Shutemov
2016-12-08 16:21 ` [RFC, PATCHv1 06/28] x86: basic changes into headers for " Kirill A. Shutemov
2016-12-08 16:21 ` Kirill A. Shutemov
2016-12-08 16:21 ` [RFC, PATCHv1 07/28] x86: trivial portion of 5-level paging conversion Kirill A. Shutemov
2016-12-08 16:21 ` Kirill A. Shutemov
2016-12-08 16:21 ` [RFC, PATCHv1 08/28] x86/gup: add 5-level paging support Kirill A. Shutemov
2016-12-08 16:21 ` Kirill A. Shutemov
2016-12-08 16:21 ` [RFC, PATCHv1 09/28] x86/ident_map: " Kirill A. Shutemov
2016-12-08 16:21 ` Kirill A. Shutemov
2016-12-08 16:21 ` [RFC, PATCHv1 10/28] x86/mm: add support of p4d_t in vmalloc_fault() Kirill A. Shutemov
2016-12-08 16:21 ` Kirill A. Shutemov
2016-12-08 16:21 ` [RFC, PATCHv1 11/28] x86/power: support p4d_t in hibernate code Kirill A. Shutemov
2016-12-08 16:21 ` Kirill A. Shutemov
2016-12-08 16:21 ` [RFC, PATCHv1 12/28] x86/kexec: support p4d_t Kirill A. Shutemov
2016-12-08 16:21 ` Kirill A. Shutemov
2016-12-08 16:21 ` [RFC, PATCHv1 13/28] x86: convert the rest of the code to " Kirill A. Shutemov
2016-12-08 16:21 ` Kirill A. Shutemov
2016-12-08 16:21 ` [RFC, PATCHv1 14/28] mm: introduce __p4d_alloc() Kirill A. Shutemov
2016-12-08 16:21 ` Kirill A. Shutemov
2016-12-08 16:21 ` [RFC, PATCHv1 15/28] x86: detect 5-level paging support Kirill A. Shutemov
2016-12-08 16:21 ` Kirill A. Shutemov
2016-12-08 20:05 ` Borislav Petkov
2016-12-08 20:08 ` Linus Torvalds
2016-12-08 20:08 ` Linus Torvalds
2016-12-08 20:20 ` Borislav Petkov
2016-12-13 22:44 ` H. Peter Anvin
2016-12-13 22:44 ` H. Peter Anvin
2016-12-13 23:07 ` Boris Petkov
2016-12-15 14:39 ` Borislav Petkov
2016-12-15 17:52 ` hpa
2016-12-15 17:52 ` hpa
2016-12-15 19:09 ` Borislav Petkov
2016-12-15 19:20 ` Andi Kleen
2016-12-15 19:20 ` Andi Kleen
2016-12-15 20:52 ` hpa
2016-12-15 20:52 ` hpa
2016-12-15 20:57 ` hpa
2016-12-15 20:57 ` hpa
2016-12-09 15:32 ` Kirill A. Shutemov
2016-12-09 15:32 ` Kirill A. Shutemov
2016-12-09 16:33 ` Borislav Petkov
2016-12-13 22:50 ` H. Peter Anvin
2016-12-13 22:50 ` H. Peter Anvin
2016-12-08 16:21 ` [RFC, PATCHv1 16/28] x86/asm: remove __VIRTUAL_MASK_SHIFT==47 assert Kirill A. Shutemov
2016-12-08 16:21 ` Kirill A. Shutemov
2016-12-08 18:39 ` Andy Lutomirski
2016-12-08 18:39 ` Andy Lutomirski
2016-12-08 19:22 ` Kirill A. Shutemov
2016-12-08 19:22 ` Kirill A. Shutemov
2016-12-08 16:21 ` [RFC, PATCHv1 17/28] x86/mm: define virtual memory map for 5-level paging Kirill A. Shutemov
2016-12-08 16:21 ` Kirill A. Shutemov
2016-12-08 18:56 ` Randy Dunlap
2016-12-08 18:56 ` Randy Dunlap
2016-12-08 19:24 ` Kirill A. Shutemov
2016-12-08 19:24 ` Kirill A. Shutemov
2016-12-08 16:21 ` [RFC, PATCHv1 18/28] x86/paravirt: make paravirt code support " Kirill A. Shutemov
2016-12-08 16:21 ` Kirill A. Shutemov
2016-12-08 16:21 ` [RFC, PATCHv1 19/28] x86/mm: basic defines/helpers for CONFIG_X86_5LEVEL Kirill A. Shutemov
2016-12-08 16:21 ` Kirill A. Shutemov
2016-12-08 16:21 ` [RFC, PATCHv1 20/28] x86/dump_pagetables: support 5-level paging Kirill A. Shutemov
2016-12-08 16:21 ` Kirill A. Shutemov
2016-12-08 16:21 ` [RFC, PATCHv1 21/28] x86/mm: extend kasan to " Kirill A. Shutemov
2016-12-08 16:21 ` Kirill A. Shutemov
2016-12-08 16:21 ` [RFC, PATCHv1 22/28] x86/espfix: " Kirill A. Shutemov
2016-12-08 16:21 ` Kirill A. Shutemov
2016-12-08 18:40 ` Andy Lutomirski
2016-12-08 18:40 ` Andy Lutomirski
2016-12-12 14:22 ` Kirill A. Shutemov
2016-12-12 14:22 ` Kirill A. Shutemov
2016-12-08 16:21 ` [RFC, PATCHv1 23/28] x86/mm: add support of additional page table level during early boot Kirill A. Shutemov
2016-12-08 16:21 ` Kirill A. Shutemov
2016-12-08 16:21 ` [RFC, PATCHv1 24/28] x86/mm: add sync_global_pgds() for configuration with 5-level paging Kirill A. Shutemov
2016-12-08 16:21 ` Kirill A. Shutemov
2016-12-08 18:42 ` Andy Lutomirski
2016-12-08 18:42 ` Andy Lutomirski
2016-12-08 19:33 ` Kirill A. Shutemov
2016-12-08 19:33 ` Kirill A. Shutemov
2016-12-08 16:21 ` [RFC, PATCHv1 25/28] x86/mm: make kernel_physical_mapping_init() support " Kirill A. Shutemov
2016-12-08 16:21 ` Kirill A. Shutemov
2016-12-08 16:21 ` [RFC, PATCHv1 26/28] x86/mm: add support for 5-level paging for KASLR Kirill A. Shutemov
2016-12-08 16:21 ` Kirill A. Shutemov
2016-12-08 16:21 ` [RFC, PATCHv1 27/28] x86: enable la57 support Kirill A. Shutemov
2016-12-08 16:21 ` Kirill A. Shutemov
2016-12-08 16:21 ` [RFC, PATCHv1 28/28] TESTING-ONLY: bump TASK_SIZE_MAX Kirill A. Shutemov
2016-12-08 16:21 ` Kirill A. Shutemov
2016-12-08 18:16 ` [RFC, PATCHv1 00/28] 5-level paging Linus Torvalds
2016-12-08 18:16 ` Linus Torvalds
2016-12-08 18:26 ` hpa
2016-12-08 18:26 ` hpa
2016-12-08 19:20 ` Kirill A. Shutemov
2016-12-08 19:20 ` Kirill A. Shutemov
2016-12-09 5:01 ` Ingo Molnar
2016-12-09 5:01 ` Ingo Molnar
2016-12-09 5:01 ` Ingo Molnar
2016-12-09 10:24 ` Arnd Bergmann [this message]
2016-12-09 10:24 ` Arnd Bergmann
2016-12-09 10:24 ` Arnd Bergmann
2016-12-09 10:51 ` Catalin Marinas
2016-12-09 10:51 ` Catalin Marinas
2016-12-09 10:51 ` Catalin Marinas
2016-12-09 10:37 ` Kirill A. Shutemov
2016-12-09 10:37 ` Kirill A. Shutemov
2016-12-09 10:37 ` Kirill A. Shutemov
2016-12-09 16:40 ` Andi Kleen
2016-12-09 16:40 ` Andi Kleen
2016-12-09 17:21 ` Kirill A. Shutemov
2016-12-09 17:21 ` Kirill A. Shutemov
2016-12-09 16:49 ` Dave Hansen
2016-12-09 16:49 ` Dave Hansen
2016-12-13 21:06 ` Dave Hansen
2016-12-13 21:06 ` Dave Hansen
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=13962749.Q2mLWEctkQ@wuerfel \
--to=arnd@arndb.de \
--cc=ak@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=ard.biesheuvel@linaro.org \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=dave.hansen@intel.com \
--cc=hpa@zytor.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@amacapital.net \
--cc=maxim.kuvyrkov@linaro.org \
--cc=mingo@kernel.org \
--cc=mingo@redhat.com \
--cc=schwidefsky@de.ibm.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=will.deacon@arm.com \
--cc=x86@kernel.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.