The QEMU project is currently moving its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting the bug state to "Incomplete" now.
If the bug has already been fixed in the latest upstream version of QEMU, then please close this ticket as "Fix released". If it is not fixed yet and you think that this bug report here is still valid, then you have two options: 1) If you already have an account on gitlab.com, please open a new ticket for this problem in our new tracker here: https://gitlab.com/qemu-project/qemu/-/issues and then close this ticket here on Launchpad (or let it expire auto- matically after 60 days). Please mention the URL of this bug ticket on Launchpad in the new ticket on GitLab. 2) If you don't have an account on gitlab.com and don't intend to get one, but still would like to keep this ticket opened, then please switch the state back to "New" or "Confirmed" within the next 60 days (other- wise it will get closed as "Expired"). We will then eventually migrate the ticket automatically to the new system (but you won't be the reporter of the bug in the new system and thus you won't get notified on changes anymore). Thank you and sorry for the inconvenience. ** Changed in: qemu Status: New => Incomplete ** Tags added: i386 tcg -- 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: Incomplete 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.ca...@linux.ibm.com To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1915327/+subscriptions