On 8/12/10, Avi Kivity <avi@xxxxxxxxxx> wrote:
> On 08/11/2010 07:22 PM, Mohammed Gamal wrote:
>> On Wed, Aug 11, 2010 at 3:08 PM, Avi Kivity<avi@xxxxxxxxxx> 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.
Hate to spoil it. I did experience the faults again with e_i_g_s=1,
although much less frequently.
What is rather really strange, is that I could get a Linux guest to
boot up completely both with e_i_g_s=1 and without it with the real
mode interrupt patch enabled. It looks to me like the problem mainly
happens when the BIOS tranfers control to the boot loader. Other
guests usually fail.
Would you like me to attach a trace?
>
> 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.
>
>
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
