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 20:48:59 -0400
Message-ID: <4C6344FB.1030005@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>	<4C62876F.1080709@redhat.com>	<4C6292C7.4000106@redhat.com> <AANLkTinMqe9WcCva9-FeYZMvGPc+rGjmYgfFa44n+T9E@mail.gmail.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]:23398 "EHLO mx1.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1758680Ab0HLAtH (ORCPT <rfc822;kvm@vger.kernel.org>);
	Wed, 11 Aug 2010 20:49:07 -0400
In-Reply-To: <AANLkTinMqe9WcCva9-FeYZMvGPc+rGjmYgfFa44n+T9E@mail.gmail.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

  On 08/11/2010 07:22 PM, Mohammed Gamal wrote:
> On Wed, Aug 11, 2010 at 3:08 PM, Avi Kivity<avi@redhat.com>  wrote:
>>   On 08/11/2010 07:20 AM, Avi Kivity wrote:
>>>   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.
>>>
>> It is initialized, I even quoted the memset().  So the problem is somewhere
>> else, we'll need more traces to find out.
>>
> I was playing around with the non-atomic-injection branch. I decided
> to use e_i_g_s=1, and it's worth noting that I never experienced these
> faults with the switch enabled.

Well, it will be interesting to see what happened.  Can you post a 
complete trace (from bootup) somewhere?


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