On 07/26/2012 04:39 PM, Mian M. Hamayun wrote: >> >> Can you share your reproducer? > Actually its based on kvm-tool and I have integrated some code from > qemu-kvm to add debug support to kvm-tool. > I don't have a smaller example that could reproduce the same problem. Then there's probably a bug there. > > The thread 3 does actually receives the signal, but the order is not right. > > As the BSP (Thread 2) starts, it locks the "qemu_global_mutex" and > releases it only when it calls the "run_on_cpu" function and starts > waiting on "qemu_work_cond". > The AP (Thread 3) wakes-up due to the SIG_IPI signal from thread 2, > acquires the lock on "qemu_global_mutex" and enters the guest mode. > (This is the deadlock case) Why would it enter guest mode? Shouldn't it execute the function you queued? > > If we do not lock the "qemu_global_mutex" in each cpu thread at the > beginning, and only lock it when we quit the guest mode, the problem > seems to go away, as now we get the SIG_IPI when the Thread 3 is > actually in the guest mode and it quits to user mode. > But I am not sure if this is the right way to do it, as in qemu-kvm we > _always_ start each cpu thread by locking the "qemu_global_mutex". Do you call KVM_SET_SIGNAL_MASK to allow the signal? -- error compiling committee.c: too many arguments to function -- 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
