From mboxrd@z Thu Jan  1 00:00:00 1970
From: Avi Kivity <avi@redhat.com>
Subject: Re: [RFC PATCH 0/3] Real mode interrupt injection
Date: Wed, 11 Aug 2010 07:20:15 -0400
Message-ID: <4C62876F.1080709@redhat.com>
References: <1281295456-11114-1-git-send-email-m.gamal005@gmail.com>	<4C60BF08.2050704@redhat.com>	<AANLkTi=nq+7hPw1XLksP+ocVoKHxBS9vUEiKmw-GF-8Q@mail.gmail.com>	<4C61DA6B.60904@redhat.com>	<AANLkTim27OZagg6rLt6-zWq8mnx2XcgntSeT51BcAa8N@mail.gmail.com> <AANLkTimmhvH2q7cCJZ+AV0OYhbvz=AZ_LLA3jU-nLdF1@mail.gmail.com> <4C6283A5.8040602@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: mtosatti@redhat.com, kvm@vger.kernel.org
To: Mohammed Gamal <m.gamal005@gmail.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mx1.redhat.com ([209.132.183.28]:45302 "EHLO mx1.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1751238Ab0HKLUT (ORCPT <rfc822;kvm@vger.kernel.org>);
	Wed, 11 Aug 2010 07:20:19 -0400
In-Reply-To: <4C6283A5.8040602@redhat.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

  On 08/11/2010 07:04 AM, Avi Kivity wrote:
>
> This is 32-bit code, yet from the trace:
>
>  qemu-system-x86-4321  [001]   150.002276: kvm_exit: reason 
> EXCEPTION_NMI rip 0x1a
>  qemu-system-x86-4321  [001]   150.002277: kvm_page_fault: address 
> d4dc error_code f
>
> The address is trimmed, so kvm thinks we're in real mode!  The '0f 00' 
> is just leftover bytes from the instruction.
>
> We'll need earlier traces to find how the mixup happened.
>

I think I have it:

static int load_segment_descriptor(struct x86_emulate_ctxt *ctxt,
                    struct x86_emulate_ops *ops,
                    u16 selector, int seg)
{
     struct desc_struct seg_desc;
     u8 dpl, rpl, cpl;
     unsigned err_vec = GP_VECTOR;
     u32 err_code = 0;
     bool null_selector = !(selector & ~0x3); /* 0000-0003 are null */
     int ret;

     memset(&seg_desc, 0, sizeof seg_desc);

     if ((seg <= VCPU_SREG_GS && ctxt->mode == X86EMUL_MODE_VM86)
         || ctxt->mode == X86EMUL_MODE_REAL) {
         /* set real mode segment descriptor */
         set_desc_base(&seg_desc, selector << 4);
         set_desc_limit(&seg_desc, 0xffff);
         seg_desc.type = 3;
         seg_desc.p = 1;
         seg_desc.s = 1;
         goto load;
     }


seg_desc is not initialized, so seg_desc.d gets a random value.  This 
selects 32-bit or 16-bit mode, and explains the confusion.  Likely the 
other case as well.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.