The backtrace of VCPU in "hangup" state is: (gdb) bt #0 0x00007f9ba661bc67 in ioctl () from /lib64/libc.so.6 #1 0x000000000069631d in kvm_vcpu_ioctl (cpu=0x169f880, type=44672) at /home/qemu-kvm-1.5.1/kvm-all.c:1735 #2 0x0000000000695bc6 in kvm_cpu_exec (env=0x169f990) at /home/qemu-kvm-1.5.1/kvm-all.c:1620 #3 0x0000000000625feb in qemu_kvm_cpu_thread_fn (arg=0x169f990) at /home/qemu-kvm-1.5.1/cpus.c:759 #4 0x00007f9ba68e0f05 in start_thread () from /lib64/libpthread.so.0 #5 0x00007f9ba662353d in clone () from /lib64/libc.so.6 There is no problem can be found from this. However, trace the VCPU thread's syscall, we can find that it only run KVM_RUN ioctl , the strace message always is: ioctl(17, 0xae80, 0) = 0 The normal VCPU thread's strace message like this: ioctl(17, 0xae80, 0) = 0 ioctl(11, 0xffffffffc008ae67, 0x7fb157ffeab0) = 0 ioctl(17, 0xae80, 0) = 0 ioctl(11, 0xffffffffc008ae67, 0x7fb157ffeab0) = 0 ioctl(17, 0xae80, 0) = 0 futex(0xf9d260, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable) futex(0xf9d260, FUTEX_WAKE_PRIVATE, 1) = 0 ioctl(17, 0xae80, 0) = 0 ioctl(17, 0xae80, 0) = 0 The issue is hard to be reproduced, except when I let the VM in idle state, it recur in several hours. Thanks --xie -----Original Message----- From: Paolo Bonzini [mailto:pbonzini@xxxxxxxxxx] Sent: Tuesday, October 15, 2013 8:30 PM To: Xiexiangyou Cc: qemu-devel@xxxxxxxxxx; qemu-devel-request@xxxxxxxxxx; kvm@xxxxxxxxxxxxxxx; Huangpeng (Peter); Luonengjun Subject: Re: [RFH] Qemu main thread is blocked in g_poll in windows guest Il 15/10/2013 14:18, Xiexiangyou ha scritto: > (gdb) bt > #0 0x00007f9ba661a423 in poll () from /lib64/libc.so.6 > #1 0x000000000059460f in os_host_main_loop_wait (timeout=4294967295) at main-loop.c:226 > #2 0x00000000005946a4 in main_loop_wait (nonblocking=0) at main-loop.c:464 > #3 0x0000000000619309 in main_loop () at vl.c:2182 > #4 0x000000000061fb5e in main (argc=54, argv=0x7fff879830c8, envp=0x7fff87983280) at vl.c:4611 This backtrace looks okay. poll is not holding the "iothread lock" and thus the VCPU thread can run QEMU code. It also looks like the VCPU thread is doing nothing special besides running KVM_RUN. Did you take the backtrace during one of these "hangups"? Paolo -- 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
