From: Sairaj Kodilkar <sarunkod@amd.com>
To: "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>,
Sairaj Kodilkar <sarunkod@amd.com>,
"Sean Christopherson" <seanjc@google.com>,
Thomas Gleixner <tglx@kernel.org>,
"Uros Bizjak" <ubizjak@gmail.com>, <kvm@vger.kernel.org>,
<linux-kernel@vger.kernel.org>, <x86@kernel.org>
Cc: <vasant.hegde@amd.com>, <suravee.suthikulpanit@amd.com>
Subject: [PATCH v2 2/2] KVM: x86: Add support for cmpxchg16b emulation
Date: Mon, 6 Jul 2026 12:00:35 +0530 [thread overview]
Message-ID: <20260706063035.1139-3-sarunkod@amd.com> (raw)
In-Reply-To: <20260706063035.1139-1-sarunkod@amd.com>
AMD and Intel both provides support for 128 bit cmpxchg operands using
cmpxchg8b/cmpxchg16b instructions (opcode 0FC7). However, kvm does not
support emulating cmpxchg16b (i.e when destination memory is 128 bit and
REX.W = 1) which causes emulation failure when QEMU guest performs a
cmpxchg16b on a memory region setup as a IO.
This failure is seen on the AMD IOMMU driver which writes 256-bit device
table entries with two 128-bit cmpxchg operations. For guests using
hardware-accelerated vIOMMU, QEMU traps device table accesses to set up
nested page tables (see [1]). Without 128-bit cmpxchg emulation, KVM
cannot handle these traps and DTE access emulation fails.
Hence extend cmpxchg8b to perform cmpxchg16b when the destination memory
is 128 bit.
[1] https://github.com/AMDESE/qemu-iommu/blob/wip/for_iommufd_hw_queue-v8_amd_viommu_20260106/hw/i386/amd_viommu.c#L517
Signed-off-by: Sairaj Kodilkar <sarunkod@amd.com>
---
arch/x86/kvm/emulate.c | 50 ++++++++++++++++++++++++++------------
arch/x86/kvm/kvm_emulate.h | 6 +++++
arch/x86/kvm/x86.c | 7 +++++-
3 files changed, 46 insertions(+), 17 deletions(-)
diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index c8e292e9a24d..9df55b3c5627 100644
--- a/arch/x86/kvm/emulate.c
+++ b/arch/x86/kvm/emulate.c
@@ -2188,24 +2188,36 @@ static int em_call_near_abs(struct x86_emulate_ctxt *ctxt)
return rc;
}
+#define em_cmpxchg8b_16b(__c, rbits, mbits)\
+do { \
+ u##mbits old = __c->dst.orig_val##mbits; \
+ \
+ BUILD_BUG_ON(rbits * 2 != mbits); \
+ \
+ if (((u##rbits) (old >> 0) != (u##rbits) reg_read(ctxt, VCPU_REGS_RAX)) || \
+ ((u##rbits) (old >> rbits) != (u##rbits) reg_read(ctxt, VCPU_REGS_RDX))) { \
+ *reg_write(ctxt, VCPU_REGS_RAX) = (u##rbits) (old >> 0); \
+ *reg_write(ctxt, VCPU_REGS_RDX) = (u##rbits) (old >> rbits); \
+ ctxt->eflags &= ~X86_EFLAGS_ZF; \
+ } else { \
+ ctxt->dst.val##mbits = ((u##mbits)reg_read(ctxt, VCPU_REGS_RCX) << rbits) | \
+ (u##rbits) reg_read(ctxt, VCPU_REGS_RBX); \
+ \
+ ctxt->eflags |= X86_EFLAGS_ZF; \
+ } \
+} while(0)
+
static int em_cmpxchg8b(struct x86_emulate_ctxt *ctxt)
{
- u64 old = ctxt->dst.orig_val64;
-
- if (ctxt->dst.bytes == 16)
+ if (WARN_ON_ONCE(8 + !!(ctxt->rex_bits & REX_W) * 8 != ctxt->dst.bytes))
return X86EMUL_UNHANDLEABLE;
- if (((u32) (old >> 0) != (u32) reg_read(ctxt, VCPU_REGS_RAX)) ||
- ((u32) (old >> 32) != (u32) reg_read(ctxt, VCPU_REGS_RDX))) {
- *reg_write(ctxt, VCPU_REGS_RAX) = (u32) (old >> 0);
- *reg_write(ctxt, VCPU_REGS_RDX) = (u32) (old >> 32);
- ctxt->eflags &= ~X86_EFLAGS_ZF;
- } else {
- ctxt->dst.val64 = ((u64)reg_read(ctxt, VCPU_REGS_RCX) << 32) |
- (u32) reg_read(ctxt, VCPU_REGS_RBX);
-
- ctxt->eflags |= X86_EFLAGS_ZF;
- }
+ if (!(ctxt->rex_bits & REX_W))
+ em_cmpxchg8b_16b(ctxt, 32, 64);
+#ifdef CONFIG_X86_64
+ else
+ em_cmpxchg8b_16b(ctxt, 64, 128);
+#endif
return X86EMUL_CONTINUE;
}
@@ -5405,8 +5417,14 @@ int x86_emulate_insn(struct x86_emulate_ctxt *ctxt, bool check_intercepts)
goto done;
}
}
- /* Copy full 64-bit value for CMPXCHG8B. */
- ctxt->dst.orig_val64 = ctxt->dst.val64;
+ /* Copy full 64/128-bit value for CMPXCHG8B. */
+
+#ifdef CONFIG_X86_64
+ if (ctxt->dst.bytes == 16)
+ ctxt->dst.orig_val128 = ctxt->dst.val128;
+ else
+#endif
+ ctxt->dst.orig_val64 = ctxt->dst.val64;
special_insn:
diff --git a/arch/x86/kvm/kvm_emulate.h b/arch/x86/kvm/kvm_emulate.h
index fb3dab4b5a53..a51677217ada 100644
--- a/arch/x86/kvm/kvm_emulate.h
+++ b/arch/x86/kvm/kvm_emulate.h
@@ -255,6 +255,9 @@ struct operand {
union {
unsigned long orig_val;
u64 orig_val64;
+#ifdef CONFIG_X86_64
+ u128 orig_val128;
+#endif
};
union {
unsigned long *reg;
@@ -268,6 +271,9 @@ struct operand {
union {
unsigned long val;
u64 val64;
+#ifdef CONFIG_X86_64
+ u128 val128;
+#endif
char valptr[sizeof(avx256_t)];
sse128_t vec_val;
avx256_t vec_val2;
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 3fb64905d190..40c84f8c4912 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -8322,7 +8322,7 @@ static int emulator_cmpxchg_emulated(struct x86_emulate_ctxt *ctxt,
int r;
/* guests cmpxchg8b have to be emulated atomically */
- if (bytes > 8 || (bytes & (bytes - 1)))
+ if (bytes > 2 * sizeof(unsigned long) || (bytes & (bytes - 1)))
goto emul_write;
gpa = kvm_mmu_gva_to_gpa_write(vcpu, addr, NULL);
@@ -8362,6 +8362,11 @@ static int emulator_cmpxchg_emulated(struct x86_emulate_ctxt *ctxt,
case 8:
r = emulator_try_cmpxchg_user(u64, hva, old, new);
break;
+#ifdef CONFIG_X86_64
+ case 16:
+ r = emulator_try_cmpxchg_user(u128, hva, old, new);
+ break;
+#endif
default:
BUG();
}
--
2.34.1
prev parent reply other threads:[~2026-07-06 6:33 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-06 6:30 [PATCH v2 0/2] Add support for cmpxchg16b emulation Sairaj Kodilkar
2026-07-06 6:30 ` [PATCH v2 1/2] x86/uaccess: Extend CMPXCHG user helpers to 128-bit operands Sairaj Kodilkar
2026-07-06 6:52 ` sashiko-bot
2026-07-06 8:00 ` Sairaj Kodilkar
2026-07-06 6:30 ` Sairaj Kodilkar [this message]
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=20260706063035.1139-3-sarunkod@amd.com \
--to=sarunkod@amd.com \
--cc=bp@alien8.de \
--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.