Re: [PATCH -tip] x86/mm: Use %RIP-relative address in untagged_addr()

[H. Peter Anvin]

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? 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.

If we really *do* care about UP builds, we could teach objtool to do 
this patching at compile time for the !SMP builds.

Also, didn't we at least use to have a way to mark a function as "init 
on UP" so that it could be jettisoned with the init code if we find 
ourselves on a uniprocessor system?

	-hpa