From: Richard Henderson <rth@twiddle.net>
To: Bug 1156313 <1156313@bugs.launchpad.net>
Cc: Torbjorn Granlund <tg@gmplib.org>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [Bug 1156313] [NEW] X86-64 flags handling broken
Date: Tue, 19 Mar 2013 11:17:32 -0700 [thread overview]
Message-ID: <5148ABBC.2090507@twiddle.net> (raw)
In-Reply-To: <20130317193406.10807.11580.malonedeb@wampee.canonical.com>
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~
next prev parent reply other threads:[~2013-03-19 18:17 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-17 19:34 [Qemu-devel] [Bug 1156313] [NEW] X86-64 flags handling broken Torbjorn Granlund
2013-03-19 18:17 ` Richard Henderson [this message]
2013-03-21 14:33 ` Torbjorn Granlund
2013-03-25 14:06 ` Torbjorn Granlund
2013-03-25 14:08 ` Peter Maydell
2013-03-25 16:09 ` Torbjorn Granlund
2017-11-07 19:10 ` [Qemu-devel] [Bug 1156313] " Peter Maydell
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=5148ABBC.2090507@twiddle.net \
--to=rth@twiddle.net \
--cc=1156313@bugs.launchpad.net \
--cc=qemu-devel@nongnu.org \
--cc=tg@gmplib.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.