Kernel KVM virtualization development
 help / color / mirror / Atom feed
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.


  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox