Re: [RFC][PATCH 0/4] x86, mpx: Support larger address space (MAWA)

[Ingo Molnar]

* Dave Hansen <dave.hansen@xxxxxxxxxxxxxxx> wrote:

> Kirill is chugging right along getting his 5-level paging[1] patch set
> ready to be merged.  I figured I'd share an early draft of the MPX
> support that will to go along with it.
> 
> Background: there is a lot more detail about what bounds tables are in
> the changelog for fe3d197f843.  But, basically MPX bounds tables help
> us to store the ranges to which a pointer is allowed to point.  The
> tables are walked by hardware and they are indexed by the virtual
> address of the pointer being checked.
> 
> A larger virtual address space (from 5-level paging) means that we
> need larger tables.  5-level paging hardware includes a feature called
> MPX Address-Width Adjust (MAWA) that grows the bounds tables so they
> can address the new address space.  MAWA is controlled independently
> from the paging mode (via an MSR) so that old MPX binaries can run on
> new hardware and kernels supporting 5-level paging.
> 
> But, since userspace is responsible for allocating the table that is
> growing (the directory), we need to ensure that userspace and the
> kernel agree about the size of these tables and the kernel can set the
> MSR appropriately.
> 
> These are not quite ready to get applied anywhere, but I don't expect
> the basics to change unless folks have big problems with this.  The
> only big remaining piece of work is to update the MPX selftest code.
> 
> Dave Hansen (4):
>       x86, mpx: introduce per-mm MPX table size tracking
>       x86, mpx: update MPX to grok larger bounds tables
>       x86, mpx: extend MPX prctl() to pass in size of bounds directory
>       x86, mpx: context-switch new MPX address size MSR

On a related note, the MPX testcases seem to have gone from the 
tools/testing/selftests/x86/Makefile (possibly a merge mishap - the original 
commit adds it correctly), so they are not being built.

Plus I noticed that the pkeys testcases are producing a lot of noise:

triton:~/tip/tools/testing/selftests/x86> make
[...]
gcc -m64 -o protection_keys_64 -O2 -g -std=gnu99 -pthread -Wall  protection_keys.c -lrt -ldl
protection_keys.c: In function âsetup_hugetlbfsâ:
protection_keys.c:816:6: warning: unused variable âiâ [-Wunused-variable]
  int i;
      ^
protection_keys.c:815:6: warning: unused variable âvalidated_nr_pagesâ [-Wunused-variable]
  int validated_nr_pages;
      ^
protection_keys.c: In function âtest_pkey_syscalls_bad_argsâ:
protection_keys.c:1136:6: warning: unused variable âbad_flagâ [-Wunused-variable]
  int bad_flag = (PKEY_DISABLE_ACCESS | PKEY_DISABLE_WRITE) + 1;
      ^
protection_keys.c: In function âtest_pkey_alloc_exhaustâ:
protection_keys.c:1153:16: warning: unused variable âinit_valâ [-Wunused-variable]
  unsigned long init_val;
                ^
protection_keys.c:1152:16: warning: unused variable âflagsâ [-Wunused-variable]
  unsigned long flags;
                ^
In file included from protection_keys.c:45:0:
pkey-helpers.h: In function âsigsafe_printfâ:
pkey-helpers.h:41:3: warning: ignoring return value of âwriteâ, declared with attribute warn_unused_result [-Wunused-result]
   write(1, dprint_in_signal_buffer, len);
   ^
protection_keys.c: In function âdumpitâ:
protection_keys.c:407:3: warning: ignoring return value of âwriteâ, declared with attribute warn_unused_result [-Wunused-result]
   write(1, buf, nr_read);
   ^
protection_keys.c: In function âpkey_disable_setâ:
protection_keys.c:68:5: warning: âorig_pkruâ may be used uninitialized in this function [-Wmaybe-uninitialized]
  if (!(condition)) {   \
     ^
protection_keys.c:465:6: note: âorig_pkruâ was declared here
  u32 orig_pkru;
      ^
[...]

Thanks,

	Ingo