Re: [PATCH v3 1/2] x86/uaccess: Extend CMPXCHG user helpers to 128-bit operands

[David Laight <david.laight.linux@gmail.com>]

On Wed, 26 Aug 2026 15:19:57 +0200
Uros Bizjak <ubizjak@gmail.com> wrote:

> On Wed, Aug 26, 2026 at 2:30 PM Dave Hansen <dave.hansen@intel.com> wrote:
> >
> > On 8/26/26 00:00, Sairaj Kodilkar wrote:  
> > > Extend the existing user CMPXCHG helpers to support 16-byte operands on
> > > x86-64, using LOCK_PREFIX "cmpxchg16b".  This mirrors the existing
> > > __try_cmpxchg64_user_asm() / cmpxchg8b path provided for 32-bit kernels,
> > > where KVM needs an atomic compare-exchange wider than the generic
> > > cmpxchg helper can provide.  
> >
> > Please take a good look at the Sashiko review:
> >
> > https://sashiko.dev/#/patchset/20260826070004.8100-2-sarunkod%40amd.com
> >
> > It looks like the "A" constraint isn't one that you can cleanly mirror
> > from cmpxchg8b => cmpxchg16b.  
> 
> Actually, "+A" will work for 64bit targets, as long as the variable is
> 128-bit. The comment in asm.h applies to 64-bit values, where on
> 32-bit targets they fit in eax *and* edx, while on 64-bit targets, the
> 64-bit values fit into rax *or* rdx.
> 
...
> 
> That said, the approach with union of two 64-bit halves can lead to
> slightly better code, because the compiler splits the value earlier in
> the compilation pipeline.

I think I agree...

From experiments I did with 64bit values on 32bit it is more the case
that the value never gets assigned to a 64bit (on 32bit) 'virtual'
register. If that ever happens all the operations are initially done
with the 'wide' register and then later split (rather than being
generated as a pair of 32bit ops).
This causes excessive register pressure and even spilling of constant
zero values to stack.
You do seem to 'get away' with returning hi << 32 | lo.

I'd guess the same happens for 128bit values on 64bit.
(This is gcc, clang does a lot better.)

David

> 
> > Uros, any chance you can give these a good once-over? This seems to be
> > just the kind of thing you've been fixing up lately. It would be nice to
> > get them right the first time.  
> 
> Based on the above explanation, these *can* be copied from 32-bit asm
> patterns. Even "q" constraint will include all integer registers on
> 64-bit targets.
> 
> Uros.
>