Messages in this thread | | | Date | Fri, 27 Jan 2017 09:16:54 +0100 | From | Ingo Molnar <> | Subject | Re: [RFC][PATCH 0/4] x86, mpx: Support larger address space (MAWA) |
| |
* Dave Hansen <dave.hansen@linux.intel.com> 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
| |