From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:46310) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UI16V-0000n1-1s for qemu-devel@nongnu.org; Tue, 19 Mar 2013 14:17:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UI16Q-0002IK-Tm for qemu-devel@nongnu.org; Tue, 19 Mar 2013 14:17:42 -0400 Received: from mail-ob0-x233.google.com ([2607:f8b0:4003:c01::233]:39945) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UI16Q-0002Ho-OQ for qemu-devel@nongnu.org; Tue, 19 Mar 2013 14:17:38 -0400 Received: by mail-ob0-f179.google.com with SMTP id un3so754965obb.38 for ; Tue, 19 Mar 2013 11:17:38 -0700 (PDT) Sender: Richard Henderson Message-ID: <5148ABBC.2090507@twiddle.net> Date: Tue, 19 Mar 2013 11:17:32 -0700 From: Richard Henderson MIME-Version: 1.0 References: <20130317193406.10807.11580.malonedeb@wampee.canonical.com> <20130317193406.10807.11580.malonedeb@wampee.canonical.com> In-Reply-To: <20130317193406.10807.11580.malonedeb@wampee.canonical.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Bug 1156313] [NEW] X86-64 flags handling broken List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Bug 1156313 <1156313@bugs.launchpad.net> Cc: Torbjorn Granlund , qemu-devel@nongnu.org On 03/17/2013 12:34 PM, Torbjorn Granlund wrote: > Public bug reported: > > The current qemu sources cause improper handling of flags on x86-64. > This bug seems to have shown up a few weeks ago. > > A plain install of Debian GNU/Linux makes user processes catch > spurious signals. The kernel seems to run stably, though. > > The ADX feature works very poorly. It might be related; at least it > allows for reproducibly provoking invalid behaviour. Patch at http://patchwork.ozlabs.org/patch/229139/ Knowing what the problem is, I'm able to reliably trigger the problem with the userland emulator. It's simply a matter of understanding how to force the right garbage values into the qemu state. E.g. .globl adx, main .type adx, @function .type main, @function adx: mov $0xdeadbeef, %eax add $0, %eax mov $0, %eax jmp 1f 1: adox %rax, %rax adcx %rax, %rax ret main: call adx lea string(%rip), %rdi mov %rax, %rsi call printf xor %eax, %eax ret .rodata: string: .asciz "result %lx\n" will always print deadbeef before the fix. Thus while having a context switch inside the loop tended to cause unpredictable behaviour, I believe it to be a red herring. r~