Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S941197AbcLMVH5 (ORCPT ); Tue, 13 Dec 2016 16:07:57 -0500 Received: from mga07.intel.com ([134.134.136.100]:27273 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932655AbcLMVHy (ORCPT ); Tue, 13 Dec 2016 16:07:54 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,342,1477983600"; d="scan'208";a="911856661" Subject: Re: [RFC, PATCHv1 00/28] 5-level paging To: Ingo Molnar , "Kirill A. Shutemov" References: <20161208162150.148763-1-kirill.shutemov@linux.intel.com> <20161209050130.GC2595@gmail.com> Cc: Linus Torvalds , Andrew Morton , x86@kernel.org, Thomas Gleixner , Ingo Molnar , Arnd Bergmann , "H. Peter Anvin" , Andi Kleen , Andy Lutomirski , linux-arch@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org From: Dave Hansen Message-ID: Date: Tue, 13 Dec 2016 13:06:35 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20161209050130.GC2595@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1624 Lines: 31 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.