From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: Can we force a KVM VCPU in Guest Mode to Exit to User Mode From User Mode ? Date: Thu, 26 Jul 2012 16:55:52 +0300 Message-ID: <50114C68.1010602@redhat.com> References: <5011102E.5020302@imag.fr> <501116A1.90607@redhat.com> <50111D51.7050809@imag.fr> <50111F59.9080103@redhat.com> <50114898.5080402@imag.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org To: mian-muhammad.hamayun@imag.fr Return-path: Received: from mx1.redhat.com ([209.132.183.28]:30913 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751767Ab2GZN4j (ORCPT ); Thu, 26 Jul 2012 09:56:39 -0400 In-Reply-To: <50114898.5080402@imag.fr> Sender: kvm-owner@vger.kernel.org List-ID: 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