From: Sairaj Kodilkar <sarunkod@amd.com>
To: Uros Bizjak <ubizjak@gmail.com>, Dave Hansen <dave.hansen@intel.com>
Cc: <sarunkod@amd.com>, "H. Peter Anvin" <hpa@zytor.com>,
"Peter Zijlstra (Intel)" <peterz@infradead.org>,
Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
Ingo Molnar <mingo@redhat.com>,
"Mathieu Desnoyers" <mathieu.desnoyers@efficios.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Sean Christopherson <seanjc@google.com>,
"Thomas Gleixner" <tglx@kernel.org>, <kvm@vger.kernel.org>,
<linux-kernel@vger.kernel.org>, <x86@kernel.org>,
<vasant.hegde@amd.com>, <suravee.suthikulpanit@amd.com>
Subject: Re: [PATCH v3 1/2] x86/uaccess: Extend CMPXCHG user helpers to 128-bit operands
Date: Wed, 26 Aug 2026 18:58:56 +0530 [thread overview]
Message-ID: <bd4d5aa3-43c4-4792-830d-ca6c58db2dbf@amd.com> (raw)
In-Reply-To: <CAFULd4YFphkN4M0a_gC=vxN8Xgh4WWBGPo8dO-o6A3v9RGX4_g@mail.gmail.com>
On 8/26/2026 6:49 PM, Uros Bizjak wrote:
> [You don't often get email from ubizjak@gmail.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> 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.
>
> This is documented in GCC documentation:
>
> ‘A’
> The ‘a’ and ‘d’ registers. This class is used for
> instructions that return double word results in the ‘ax:dx’
> register pair. Single word values will be allocated either in
> ‘ax’ or ‘dx’.
>
> And can be confirmed with e.g.:
>
> __int128 val;
>
> void foo (void)
> {
> __int128 _v = val;
> asm volatile ("" : "+A" (_v));
> val = _v;
> }
>
> which will fail compilation with -ffixed-rax or -ffixed-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.
>
>> 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.
Yep, this is what I was trying to say in my reply to sashiko. Basically
+A can be safely used for 64 bit values on 32 bit machines and 128 bit
values on 64 bit machines.
Also if you prefer split one, I can do that as well.
Sairaj
>
> Uros.
next prev parent reply other threads:[~2026-08-26 13:29 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-26 7:00 [PATCH v3 0/2] Add support for cmpxchg16b emulation Sairaj Kodilkar
2026-08-26 7:00 ` [PATCH v3 1/2] x86/uaccess: Extend CMPXCHG user helpers to 128-bit operands Sairaj Kodilkar
2026-08-26 7:23 ` sashiko-bot
2026-08-26 8:54 ` Sairaj Kodilkar
2026-08-26 12:30 ` Dave Hansen
2026-08-26 13:19 ` Uros Bizjak
2026-08-26 13:28 ` Sairaj Kodilkar [this message]
2026-08-27 9:01 ` David Laight
2026-08-26 7:00 ` [PATCH v3 2/2] KVM: x86: Add support for cmpxchg16b emulation Sairaj Kodilkar
2026-08-26 7:31 ` sashiko-bot
2026-08-26 9:17 ` Sairaj Kodilkar
2026-08-26 12:50 ` Mathieu Desnoyers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bd4d5aa3-43c4-4792-830d-ca6c58db2dbf@amd.com \
--to=sarunkod@amd.com \
--cc=bp@alien8.de \
--cc=dave.hansen@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=seanjc@google.com \
--cc=suravee.suthikulpanit@amd.com \
--cc=tglx@kernel.org \
--cc=ubizjak@gmail.com \
--cc=vasant.hegde@amd.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.