Messages in this thread | | | From | Brian Gerst <> | Date | Fri, 17 Nov 2023 14:43:17 -0500 | Subject | Re: [PATCH -tip] x86/mm: Use %RIP-relative address in untagged_addr() |
| |
On Fri, Nov 17, 2023 at 1:16 PM H. Peter Anvin <hpa@zytor.com> wrote: > > On 11/16/23 11:10, Uros Bizjak wrote: > > %RIP-relative addresses are nowadays correctly handled in alternative > > instructions, so remove misleading comment and improve assembly to > > use %RIP-relative address. > > > > Also, explicitly using %gs: prefix will segfault for non-SMP builds. > > Use macros from percpu.h which will DTRT with segment prefix register > > as far as SMP/non-SMP builds are concerned. > > OK, this is starting to feel silly. One could seriously question the use > case for supporting !SMP builds x86-64. It isn't like our performance > for SMP builds on UP systems is significantly worse, it is mostly just a > matter of code size, and the difference isn't huge, either, especially > considering that on systems of the x86-64 era the kernel is a rather > small part of system memory (unlike the very early i386 era, for those > of us who remember those ancient times.) > > The number of UP x86-64 systems is really very small (since > multicore/SMT became ubiquitous at roughly the same time x86-64 was > introduced), and as far as I know none of them lack APIC which is really > the most fundamental difference between SMP and !SMP on x86. > > Why don't we simply have %gs_base == 0 as an invariant for !SMP?
The reason is stack protector, which is still stuck at %gs:40. So GSBASE has to point at fixed_percpu_data, even on a UP build. That is corrected by the patch series I recently posted, though.
> If we > *REALLY* care to skip SWAPGS on !SMP systems, we could use alternatives > to patch out %gs: and lock (wouldn't even have to be explicit: this is > the kind of thing that objtool does really well.) We can use > alternatives without anything special, since it only matters after we > have entered user spae for the first time and would be concurrent with > patching out SWAPGS itself.
There is already support to patch out LOCK prefixes when running an SMP build on a single CPU (.smp_locks section). Patching out the GS prefix would only work if the initial percpu area is not freed. Beyond that I don't think other optimizations are worth the effort, and would get very little testing.
Brian Gerst
| |