Re: [RFC, PATCHv1 00/28] 5-level paging

Path	csiph.com!feeder.erje.net!1.eu.feeder.erje.net!news.in-chemnitz.de!news2.arglkargh.de!news.mixmin.net!aioe.org!bofh.it!news.nic.it!robomod
From	Dave Hansen <dave.hansen@intel.com>
Newsgroups	linux.kernel
Subject	Re: [RFC, PATCHv1 00/28] 5-level paging
Date	Tue, 13 Dec 2016 22:10:02 +0100
Message-ID	<sO2uK-683-65@gated-at.bofh.it> (permalink)
References	<sM9K2-8la-5@gated-at.bofh.it> <sMlBw-7ym-5@gated-at.bofh.it>
X-Extloop1	1
X-Ironport-Av	E=Sophos;i="5.33,342,1477983600"; d="scan'208";a="911856661"
User-Agent	Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version	1.0
Content-Type	text/plain; charset=utf-8
Content-Transfer-Encoding	7bit
Sender	robomod@news.nic.it
List-ID	<linux-kernel.vger.kernel.org>
X-Mailing-List	linux-kernel@vger.kernel.org
Approved	robomod@news.nic.it
Lines	31
Organization	linux.* mail to news gateway
X-Original-Cc	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>, Arnd Bergmann <arnd@arndb.de>, "H. Peter Anvin" <hpa@zytor.com>, Andi Kleen <ak@linux.intel.com>, Andy Lutomirski <luto@amacapital.net>, linux-arch@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org
X-Original-Date	Tue, 13 Dec 2016 13:06:35 -0800
X-Original-Message-ID	<a2f86495-b55f-fda0-40d2-242c45d3c1f3@intel.com>
X-Original-References	<20161208162150.148763-1-kirill.shutemov@linux.intel.com> <20161209050130.GC2595@gmail.com>
X-Original-Sender	linux-kernel-owner@vger.kernel.org
Xref	csiph.com linux.kernel:1541529

Show key headers only | View raw

On 12/08/2016 09:01 PM, 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.

MPX is going to be a real pain here.  It is relatively transparent to
applications that use it, and old MPX binaries are entirely incompatible
with the new address space size, so an opt-out wouldn't be friendly.

Because the top-level MPX bounds table is indexed by the virtual
address, a growth in vaddr space is going to require the table to grow
(or change somehow).  The solution baked into the hardware spec is to
just make the top-level table 512x larger to accommodate the 512x
increase in vaddr space.  (This behavior is controlled by a new MSR, btw...)

So, either we disable MPX on all old MPX binaries by returning an error
when the prctl() tries to enable MPX and 5-level paging is on, or we go
with some form of an opt-in.  New MPX binaries will opt-in to the larger
address space since they know to allocate the new, larger table.

Back to linux.kernel | Previous | Next | Find similar | Unroll thread

Thread

Re: [RFC, PATCHv1 00/28] 5-level paging Dave Hansen <dave.hansen@intel.com> - 2016-12-13 22:10 +0100

csiph-web