Messages in this thread | | | From | Andy Lutomirski <> | Date | Fri, 7 Sep 2018 21:32:54 -0700 | Subject | Re: [PATCH v2 3/3] x86/pti/64: Remove the SYSCALL64 entry trampoline |
| |
On Fri, Sep 7, 2018 at 5:04 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote: > On Fri, Sep 7, 2018 at 12:54 PM Thomas Gleixner <tglx@linutronix.de> wrote: >> >> > - We execute from an extra page and read from another extra page >> > during the syscall. (The latter is because we need to use a relative >> > addressing mode to find sp1 -- it's the same *cacheline* we'd use >> > anyway, but we're accessing it using an alias, so it's an extra TLB >> > entry.) >> >> Ok, but is this really an issue with PTI? > > I'd expect it to be *more* of an issue with PTI, since you're already > wasting TLB entries due to the whole "two different page tables". > > Sure, address space ID's save you from reloading them all the time, > but don't help with capacity. > > But yeah, in the sense of "with PTI, all kernel entries are slow > anyway, so none of this matters" is probably correct in a very real > sense. > > That said, the real reason I like Andy's patch series is that I think > it's simpler than the alternatives (including the current setup). No > subtle mappings, no nothing. It removes a lot more lines than it adds, > and half the lines that it *does* add are comments. > > Virtual mapping tricks may be cool, but in the end, not having to use > them is better still, I think. >
If (and this is a *big* if) all the percpu data is within 2GB of the entry text, then we could avoid this extra TLB reference by accessing it directly instead of using an alias.
I suppose the summary is that the retpoline-free trampoline variant is even more complicated than the code I'm removing in this series, and that it would be at best a teeny tiny win. Once all the Spectre dust settles and we get fixed CPUs, we could consider re-optimizing this.
| |