From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NFmvn-0002H3-AZ for qemu-devel@nongnu.org; Wed, 02 Dec 2009 05:59:35 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NFmvi-0002FQ-Fe for qemu-devel@nongnu.org; Wed, 02 Dec 2009 05:59:34 -0500 Received: from [199.232.76.173] (port=48921 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NFmvi-0002FC-7R for qemu-devel@nongnu.org; Wed, 02 Dec 2009 05:59:30 -0500 Received: from mx1.redhat.com ([209.132.183.28]:48233) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NFmvh-0006sB-T6 for qemu-devel@nongnu.org; Wed, 02 Dec 2009 05:59:30 -0500 Date: Wed, 2 Dec 2009 12:59:27 +0200 From: Gleb Natapov Subject: Re: [Qemu-devel] [PATCH v2 0/11] Message-ID: <20091202105927.GB9537@redhat.com> References: <1259671897-22232-1-git-send-email-glommer@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1259671897-22232-1-git-send-email-glommer@redhat.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Glauber Costa Cc: agraf@suse.de, aliguori@us.ibm.com, qemu-devel@nongnu.org, avi@redhat.com On Tue, Dec 01, 2009 at 10:51:26AM -0200, Glauber Costa wrote: > This is a repost of the -smp series. Note that it depends on irqchip-in-kernel, > that is already in staging. Also, you'll have to enable the io-thread, for the time > being. > > >From the last version, main change is that I am not calling queue_work automatically > from vcpu ioctls. queue_work is only used currently for the gdb stub. > > All other uses were by-passed by the new qemu_register_vcpu_reset(), since most > of it uses (all racy) came from the reset handlers. > Looks good to me except one thing. I don't see how you are addressing the problem fixed by commit b8a7857071b477b28d3055e33ff0298fc91f329a in qemu-kvm. The problem is that mp_state can change in kernel between call to kvm_cpu_synchronize_state() and vcpu re-entry. In this case old mp_state will overwrite new one. -- Gleb.