lkml.org 
[lkml]   [2016]   [Dec]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC, PATCHv1 00/28] 5-level paging
From
Date
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.

\
 
 \ /
  Last update: 2016-12-13 22:09    [W:0.188 / U:0.552 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site