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 <m...@tls.msk.ru> wrote: >>> ... >>>>>> Ok, I can reproduce this, winXP BSODs on boot in tcg mode. >>>>>> Git bisect points to this: >>>>>> >>>>>> commit 23820dbfc79d1c9dce090b4c555994f2bb6a69b3 >>>>>> Author: Peter Crosthwaite <peter.crosthwa...@xilinx.com> >>>>>> 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 (sig=sig@entry=6) 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 (sig=sig@entry=6) 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", > assertion=assertion@entry=0x7993e2 "xplen == *plen", > file=file@entry=0x799370 "/home/build/src/qemu/git/qemu/exec.c", > line=line@entry=362, function=function@entry=0x799be0 > <__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.