[Bug 1915327] [NEW] x86_64 cmpxchg behavior in qemu tcg does not match the real CPU

[Ilya Leoshkevich]

Public bug reported:

QEMU version:
1214d55d1c (HEAD, origin/master, origin/HEAD) Merge remote-tracking branch 
'remotes/nvme/tags/nvme-next-pull-request' into staging

Consider the following little program:

$ cat 1.c
#include <stdio.h>
int main() {
  int mem = 0x12345678;
  register long rax asm("rax") = 0x1234567812345678;
  register int edi asm("edi") = 0x77777777;
  asm("cmpxchg %[edi],%[mem]"
      : [ mem ] "+m"(mem), [ rax ] "+r"(rax)
      : [ edi ] "r"(edi));
  long rax2 = rax;
  printf("rax2 = %lx\n", rax2);
}

According to the Intel Manual, cmpxchg should not touch the accumulator
in case the values are equal, which is indeed the case on the real CPU:

$ gcc 1.c
$ ./a.out 
rax2 = 1234567812345678

However, QEMU appears to zero extend EAX to RAX:

$ qemu-x86_64 ./a.out 
rax2 = 12345678

This is also the case for lock cmpxchg.

Found in BPF development context:
https://lore.kernel.org/bpf/b1792bb3c51eb3e94b9d27e67665d3f2209bba7e.camel@linux.ibm.com

** Affects: qemu
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1915327

Title:
  x86_64 cmpxchg behavior in qemu tcg does not match the real CPU

Status in QEMU:
  New

Bug description:
  QEMU version:
  1214d55d1c (HEAD, origin/master, origin/HEAD) Merge remote-tracking branch 
'remotes/nvme/tags/nvme-next-pull-request' into staging

  Consider the following little program:

  $ cat 1.c
  #include <stdio.h>
  int main() {
    int mem = 0x12345678;
    register long rax asm("rax") = 0x1234567812345678;
    register int edi asm("edi") = 0x77777777;
    asm("cmpxchg %[edi],%[mem]"
        : [ mem ] "+m"(mem), [ rax ] "+r"(rax)
        : [ edi ] "r"(edi));
    long rax2 = rax;
    printf("rax2 = %lx\n", rax2);
  }

  According to the Intel Manual, cmpxchg should not touch the
  accumulator in case the values are equal, which is indeed the case on
  the real CPU:

  $ gcc 1.c
  $ ./a.out 
  rax2 = 1234567812345678

  However, QEMU appears to zero extend EAX to RAX:

  $ qemu-x86_64 ./a.out 
  rax2 = 12345678

  This is also the case for lock cmpxchg.

  Found in BPF development context:
  
https://lore.kernel.org/bpf/b1792bb3c51eb3e94b9d27e67665d3f2209bba7e.camel@linux.ibm.com

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1915327/+subscriptions