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 13:06:25 +0300 Message-ID: <501116A1.90607@redhat.com> References: <5011102E.5020302@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]:51504 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751252Ab2GZKGc (ORCPT ); Thu, 26 Jul 2012 06:06:32 -0400 In-Reply-To: <5011102E.5020302@imag.fr> Sender: kvm-owner@vger.kernel.org List-ID: On 07/26/2012 12:38 PM, Mian M. Hamayun wrote: > > This mechanism 'seems' to work fine when both vcpu threads are in User > Mode. But when booting an SMP Guest, the boot processor (BSP) initially > executes the bootstrap code while the non-boot processors (APs) are > waiting for initial INIT-SIPI-SIPI messages. > > What I fail to understand is if an AP is currently waiting for an INIT > signal, and we call the "run_on_cpu" function above for this cpu, it > blocks the whole system, as the AP is in Guest mode and cannot call the > "flush_queued_work" and the BSP is waiting for this to happen. > > How can we resolve this deadlock ? Is there a way to force the AP to > quit the Guest Mode, by using some specific mechanism from the User mode ? When a vcpu is waiting for an INIT, it still responds to signals and will return to userspace if a signal is received. Did you observe something different? -- error compiling committee.c: too many arguments to function