From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44001) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YVGcp-0000vJ-2v for qemu-devel@nongnu.org; Tue, 10 Mar 2015 05:38:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YVGcm-0004hw-Az for qemu-devel@nongnu.org; Tue, 10 Mar 2015 05:38:55 -0400 Received: from mail-wi0-x22a.google.com ([2a00:1450:400c:c05::22a]:36584) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YVGcm-0004ho-4E for qemu-devel@nongnu.org; Tue, 10 Mar 2015 05:38:52 -0400 Received: by wiwh11 with SMTP id h11so18144856wiw.1 for ; Tue, 10 Mar 2015 02:38:51 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <54FEBBA7.20400@redhat.com> Date: Tue, 10 Mar 2015 10:38:47 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <201503091548.01462.wpaul@windriver.com> In-Reply-To: <201503091548.01462.wpaul@windriver.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Fix for incorrect SYSRET instruction implementation -- anyone looked at this yet? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Bill Paul , qemu-devel 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 > > --- > 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