qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Bug report - Windows XP guest failure


From: Programmingkid
Subject: Re: [Qemu-devel] Bug report - Windows XP guest failure
Date: Sun, 14 Jun 2015 10:56:27 -0400

On Jun 14, 2015, at 5:55 AM, Mark Cave-Ayland wrote:

> On 13/05/15 10:01, Paolo Bonzini wrote:
> 
>> On 12/05/2015 09:22, Michael Tokarev wrote:
>>> 12.05.2015 04:05, Peter Crosthwaite wrote:
>>>> On Thu, May 7, 2015 at 2:34 AM, Michael Tokarev <address@hidden> wrote:
>>> ...
>>>>>> Ok, I can reproduce this, winXP BSODs on boot in tcg mode.
>>>>>> Git bisect points to this:
>>>>>> 
>>>>>> commit 23820dbfc79d1c9dce090b4c555994f2bb6a69b3
>>>>>> Author: Peter Crosthwaite <address@hidden>
>>>>>> Date:   Mon Mar 16 22:35:54 2015 -0700
>>>>>> 
>>>>>>    exec: Respect as_translate_internal length clamp
>>>>> 
>>>>> This winXP BSOD happens on x86_64 target too.  Reverting the
>>>>> above commit from git master fixes the BSOD.
>>>> 
>>>> Any useful info about IO addresses on that BSOD? The last issue with
>>>> this patch was IOPort code relying on the bug that this patch fixed.
>>>> This could be similar and if we can track the failure to a particular
>>>> address we can fix properly rather than another revert of that patch.
>>> 
>>> Oh.  I didn't know this patch has been reverted before.  Anyway, I disabled
>>> auto-reboot on BSOD on my winXP (what a "useful" feature!) and here's what
>>> I see.
>>> 
>>>  IRQ_NOT_LESS_OR_EQUAL
>>>  STOP: 0x0A (0x16, 0x02, 0x00, 0x80500EFC)
>>> 
>>> (with some amount of leading zeros stripped).
>>> 
>>> When this happens, win does something for quite some time, the BSOD comes
>>> after quite significant delay.
>>> 
>>> Is there anything else I can look at, maybe some crash dump or something?
>>> I haven't done any windows debugging before.
>> 
>> I would just put a breakpoint on the new condition introduced by the
>> commit, and see what causes the breakage.
> 
> I tried this approach and came up with the following backtrace:
> 
> Program received signal SIGABRT, Aborted.
> [Switching to Thread 0x7ffff1bfc700 (LWP 30219)]
> 0x00007ffff5ccf107 in __GI_raise (address@hidden) at
> ../nptl/sysdeps/unix/sysv/linux/raise.c:56
> 56      ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
> (gdb) bt
> #0  0x00007ffff5ccf107 in __GI_raise (address@hidden) at
> ../nptl/sysdeps/unix/sysv/linux/raise.c:56
> #1  0x00007ffff5cd04e8 in __GI_abort () at abort.c:89
> #2  0x00007ffff5cc8226 in __assert_fail_base (fmt=0x7ffff5dfece8
> "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n",
> address@hidden "xplen == *plen",
>    address@hidden "/home/build/src/qemu/git/qemu/exec.c",
> address@hidden, address@hidden
> <__PRETTY_FUNCTION__.34759> "address_space_translate_internal") at
> assert.c:92
> #3  0x00007ffff5cc82d2 in __GI___assert_fail (assertion=0x7993e2 "xplen
> == *plen", file=0x799370 "/home/build/src/qemu/git/qemu/exec.c", line=362,
>    function=0x799be0 <__PRETTY_FUNCTION__.34759>
> "address_space_translate_internal") at assert.c:101
> #4  0x000000000040b54b in address_space_translate_internal
> (d=0x7fffdc127150, addr=0, xlat=0x7ffff1bfb470, plen=0x7ffff1bfb530,
> resolve_subpage=true) at /home/build/src/qemu/git/qemu/exec.c:362
> #5  0x000000000040b643 in address_space_translate (as=0xc1b8c0
> <address_space_io>, addr=0, xlat=0x7ffff1bfb540, plen=0x7ffff1bfb530,
> is_write=true) at /home/build/src/qemu/git/qemu/exec.c:390
> #6  0x000000000040fa54 in address_space_rw (as=0xc1b8c0
> <address_space_io>, addr=126, attrs=..., buf=0x7ffff1bfb5c0 "\001",
> len=4, is_write=true) at /home/build/src/qemu/git/qemu/exec.c:2339
> #7  0x000000000040fe19 in address_space_write (as=0xc1b8c0
> <address_space_io>, addr=126, attrs=..., buf=0x7ffff1bfb5c0 "\001",
> len=4) at /home/build/src/qemu/git/qemu/exec.c:2431
> #8  0x000000000044ef97 in cpu_outl (addr=126, val=1) at
> /home/build/src/qemu/git/qemu/ioport.c:89
> #9  0x0000000000517104 in helper_outl (port=126, data=1) at
> /home/build/src/qemu/git/qemu/target-i386/misc_helper.c:47
> #10 0x0000000040557d03 in code_gen_buffer ()
> #11 0x0000000000414916 in cpu_tb_exec (cpu=0x111cc30, tb_ptr=0x40557ce0
> <code_gen_buffer+5602528> "A\213n\374\205\355\017\205\067") at
> /home/build/src/qemu/git/qemu/cpu-exec.c:199
> #12 0x0000000000415351 in cpu_x86_exec (env=0x1124e80) at
> /home/build/src/qemu/git/qemu/cpu-exec.c:519
> #13 0x00000000004404e4 in tcg_cpu_exec (env=0x1124e80) at
> /home/build/src/qemu/git/qemu/cpus.c:1354
> #14 0x00000000004405cb in tcg_exec_all () at
> /home/build/src/qemu/git/qemu/cpus.c:1387
> #15 0x000000000043fb7c in qemu_tcg_cpu_thread_fn (arg=0x111cc30) at
> /home/build/src/qemu/git/qemu/cpus.c:1032
> #16 0x00007ffff604b0a4 in start_thread (arg=0x7ffff1bfc700) at
> pthread_create.c:309
> #17 0x00007ffff5d8004d in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
> (gdb) p/x 126
> $1 = 0x7e
> 
> It looks like we're trying to do a 32-bit write to the kvmvapic device
> which appears as below in "info mtree":
> 
> address-space: I/O
>  0000000000000000-000000000000ffff (prio 0, RW): io
>    0000000000000000-0000000000000007 (prio 0, RW): dma-chan
>    0000000000000008-000000000000000f (prio 0, RW): dma-cont
>    0000000000000020-0000000000000021 (prio 0, RW): pic
>    0000000000000040-0000000000000043 (prio 0, RW): pit
>    0000000000000060-0000000000000060 (prio 0, RW): i8042-data
>    0000000000000061-0000000000000061 (prio 0, RW): pcspk
>    0000000000000064-0000000000000064 (prio 0, RW): i8042-cmd
>    0000000000000070-0000000000000071 (prio 0, RW): rtc
>    000000000000007e-000000000000007f (prio 0, RW): kvmvapic
>    0000000000000080-0000000000000080 (prio 0, RW): ioport80
> 
> According to the comments in kvmvapic.c's vapic_write(), a 32-bit write
> is used to poll for pending IRQs. However with the address clamping
> enabled, these writes never make it to the kvmvapic which is what causes
> the breakage in WinXP.
> 
> 
> ATB,
> 
> Mark.

Good job figuring this out. 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]