From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NFoHE-0001vo-Fs for qemu-devel@nongnu.org; Wed, 02 Dec 2009 07:25:48 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NFoH9-0001rj-Kg for qemu-devel@nongnu.org; Wed, 02 Dec 2009 07:25:47 -0500 Received: from [199.232.76.173] (port=37317 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NFoH9-0001rR-6T for qemu-devel@nongnu.org; Wed, 02 Dec 2009 07:25:43 -0500 Received: from david.siemens.de ([192.35.17.14]:23166) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NFoH8-0006Nq-Oc for qemu-devel@nongnu.org; Wed, 02 Dec 2009 07:25:43 -0500 Message-ID: <4B165CC3.4060805@siemens.com> Date: Wed, 02 Dec 2009 13:25:39 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <1259671897-22232-1-git-send-email-glommer@redhat.com> <20091202105927.GB9537@redhat.com> <4B1657C0.20104@siemens.com> <20091202122250.GC9537@redhat.com> In-Reply-To: <20091202122250.GC9537@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH v2 0/11] List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gleb Natapov Cc: "qemu-devel@nongnu.org" , Glauber Costa , "avi@redhat.com" , "agraf@suse.de" , "aliguori@us.ibm.com" Gleb Natapov wrote: > On Wed, Dec 02, 2009 at 01:04:16PM +0100, Jan Kiszka wrote: >> Gleb Natapov wrote: >>> 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. >> + nmi_pending >> + sipi_vector >> >> These things need to be fixed at kernel level as discussed recently: >> Asynchronous changes done by in-kernel subsystems need to be queued and >> replayed with a higher priority than user space changes. User space need >> to stop the vm if it does not want to be overruled. >> > Long term yes. Short term qemu need to work with existing kernels. Avi's answer was different [1]. Jan [1] http://permalink.gmane.org/gmane.comp.emulators.kvm.devel/43288 -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux