From: Paolo Bonzini <pbonzini@redhat.com>
To: Bill Paul <wpaul@windriver.com>, qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] Fix for incorrect SYSRET instruction implementation -- anyone looked at this yet?
Date: Tue, 10 Mar 2015 10:38:47 +0100 [thread overview]
Message-ID: <54FEBBA7.20400@redhat.com> (raw)
In-Reply-To: <201503091548.01462.wpaul@windriver.com>
On 09/03/2015 23:48, Bill Paul wrote:
> I'm certain I'm sending this in plain text mode this time. According to my
> reading of the Intel documentation, the SYSRET instruction is supposed to
> force the RPL bits of the %ss register to 3 when returning to user mode. The
> actual sequence is:
>
> SS.Selector <-- (IA32_STAR[63:48]+8) OR 3; (* RPL forced to 3 *)
>
> However, the code in helper_sysret() leaves them at 0 (in other words, the "OR
> 3" part of the above sequence is missing). It does set the privilege level
> bits of %cs correctly though.
>
> This has caused me trouble with some of my VxWorks development: code that runs
> okay on real hardware will crash on QEMU, unless I apply the patch below.
>
> Can someone confirm that this is in fact a real bug? The Intel architecture
> manual seems quite clear about the SYSRET behavior. The bug seems to have been
> around as far back as QEMU 0.10.5.
>
> I am using QEMU 2.2.0 on FreeBSD/amd64 9.1-RELEASE.
>
> -Bill
>
> Signed-off-by: Bill Paul <wpaul@windriver.com>
>
> ---
> target-i386/seg_helper.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/target-i386/seg_helper.c b/target-i386/seg_helper.c
> index fa374d0..2bc757a 100644
> --- a/target-i386/seg_helper.c
> +++ b/target-i386/seg_helper.c
> @@ -1043,7 +1043,7 @@ void helper_sysret(CPUX86State *env, int dflag)
> DESC_CS_MASK | DESC_R_MASK | DESC_A_MASK);
> env->eip = (uint32_t)env->regs[R_ECX];
> }
> - cpu_x86_load_seg_cache(env, R_SS, selector + 8,
> + cpu_x86_load_seg_cache(env, R_SS, (selector + 8) | 3,
> 0, 0xffffffff,
> DESC_G_MASK | DESC_B_MASK | DESC_P_MASK |
> DESC_S_MASK | (3 << DESC_DPL_SHIFT) |
> @@ -1056,7 +1056,7 @@ void helper_sysret(CPUX86State *env, int dflag)
> DESC_S_MASK | (3 << DESC_DPL_SHIFT) |
> DESC_CS_MASK | DESC_R_MASK | DESC_A_MASK);
> env->eip = (uint32_t)env->regs[R_ECX];
> - cpu_x86_load_seg_cache(env, R_SS, selector + 8,
> + cpu_x86_load_seg_cache(env, R_SS, (selector + 8) | 3,
> 0, 0xffffffff,
> DESC_G_MASK | DESC_B_MASK | DESC_P_MASK |
> DESC_S_MASK | (3 << DESC_DPL_SHIFT) |
>
Applied, thanks. I will send a pull request today.
Paolo
next prev parent reply other threads:[~2015-03-10 9:38 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-09 22:48 [Qemu-devel] Fix for incorrect SYSRET instruction implementation -- anyone looked at this yet? Bill Paul
2015-03-10 8:29 ` Fam Zheng
2015-03-10 9:38 ` Paolo Bonzini [this message]
-- strict thread matches above, loose matches on Subject: below --
2015-03-09 22:02 Bill Paul
2015-03-09 22:23 ` Stefan Weil
2015-03-09 22:46 ` Bill Paul
2015-03-10 5:46 ` Stefan Weil
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=54FEBBA7.20400@redhat.com \
--to=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=wpaul@windriver.com \
/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.