On Tue, Oct 31, 2017 at 3:31 PM, Dave Hansen <dave.hansen@xxxxxxxxxxxxxxx> wrote: > > These patches are based on work from a team at Graz University of > Technology posted here: https://github.com/IAIK/KAISER > I think we're far enough along here that it may be time to nail down the memory layout for real. I propose the following: The user tables will contain the following: - The GDT array. - The IDT. - The vsyscall page. We can make this be _PAGE_USER. - The TSS. - The per-cpu entry stack. Let's make it one page with guard pages on either side. This can replace rsp_scratch. - cpu_current_top_of_stack. This could be in the same page as the TSS. - The entry text. - The percpu IST (aka "EXCEPTION") stacks. That's it. We can either try to move all of the above into the fixmap or we can have the user tables be sparse a la Dave's current approach. If we do it the latter way, I think we'll want to add a mechanism to have holes in the percpu space to give the entry stack a guard page. I would *much* prefer moving everything into the fixmap, but that's a wee bit awkward because we can't address per-cpu data in the fixmap using %gs, which makes the SYSCALL code awkward. But we could alias the SYSCALL entry text itself per-cpu into the fixmap, which lets us use %rip-relative addressing, which is quite nice. So I guess my preference is to actually try the fixmap approach. We give the TSS the same aliasing treatment we gave the GDT, and I can try to make the entry trampoline work through the fixmap and thus not need %gs-based addressing until CR3 gets updated. (This actually saves several cycles of latency.) What do you all think? I'll deal with the LDT separately. It will either live in the fixmap-like region or it will live at the top of the user address space. [1] https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/log/?h=x86/entry_consolidation -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
