Reworking page-table traversal [LWN.net]

Reworking page-table traversal

Posted May 6, 2018 17:37 UTC (Sun) by willy (subscriber, #9762)
In reply to: Reworking page-table traversal by pbonzini
Parent article: Reworking page-table traversal

No, it's 5 levels on z/Arch. 11+11+11+11+8+12 =64
x86 uses 9+9+9+9+9+12 = 57 bits

Source: first result on
https://www.google.ca/search?q=zseries+page+table+site%3A...
(Hard to get a direct link to a PDF on Android)

If x86 were willing to switch to an 8k page size, 5 level paging would get them 63 bits.

Reworking page-table traversal

Posted May 8, 2018 23:53 UTC (Tue) by luto (subscriber, #39314) [Link] (1 responses)

There’s no need for an 8k page. All that would be needed is bigger page table chunks. 8k (i.e. two-page) directories with 8-byte entries gives 10 bits of VA per level. 12+5*10 = 62 bits. Now give separate roots for the top and bottom halves of the address space and 63 of the 64 possible bits are covered.

Intel, if you ever revamp the page table format again, here are some feature requests:

- Separate R, W, and X bits.

- Separate page table roots for the top and bottom halves of the address space. Or, even better, separate user-mode and kernel-mode page tables.

- At least one extra address space accessible with prefixes or special instructions. For example, having the stack live in a separate address space accessible only with PUSH, POP, and prefixed memory operands would be awesome.

(Hmm. There are already mostly-useless CS, SS, DS, ES, FS, and GS prefixes. Make each one refer to a separate address space. Make ES, FS, and GS be usable only at CPL0, and make CPL0 default to the ES space and CPL > 0 default to CS.)

Reworking page-table traversal

Posted May 10, 2018 20:54 UTC (Thu) by kiryl (subscriber, #41516) [Link]

8-byte entries is not enough. We already run out of bits in the entries and every new feature wants to claim one (or 15 with MKTME :P).

Why is separate roots from kernel/user useful? Is it only to protect against Meltdown-alike stuff?