Messages in this thread | | | Date | Mon, 27 Nov 2017 10:14:24 +0100 | From | Peter Zijlstra <> | Subject | Re: [PATCH 30/43] x86/mm/kaiser: Map espfix structures |
| |
On Fri, Nov 24, 2017 at 08:17:06AM -0800, Andy Lutomirski wrote: > On Fri, Nov 24, 2017 at 5:47 AM, Peter Zijlstra <peterz@infradead.org> wrote: > > On Fri, Nov 24, 2017 at 10:14:35AM +0100, Ingo Molnar wrote: > >> From: Dave Hansen <dave.hansen@linux.intel.com> > >> > >> There is some rather arcane code to help when an IRET returns > >> to 16-bit segments. It is referred to as the "espfix" code. > >> This consists of a few per-cpu variables: > >> > >> espfix_stack: tells us where the stack is allocated > >> (the bottom) > >> espfix_waddr: tells us to where %rsp may be pointed > >> (the top) > >> > >> These are in addition to the stack itself. All three things must > >> be mapped for the espfix code to function. > >> > >> Note: the espfix code runs with a kernel GSBASE, but user > >> (shadow) page tables. A switch to the kernel page tables could > >> be performed instead of mapping these structures, but mapping > >> them is simpler and less likely to break the assembly. To switch > >> over to the kernel copy, additional temporary storage would be > >> required which is in short supply in this context. > > > > With Andy's patches that should actually be doable, no? > > I don't think it has much to do with my patches. We can freely spill > to the stack in the espfix64 code, though.
Ah, I was thinking of how you made scratch space easier for the SYSENTER stuff.
But if we can freely spill here, should we not do the kernel switch instead of doing this user mapping? The way I understand things, the less of these magic mappings we have the better.
| |