From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1NFoEV-0007zU-5g
	for qemu-devel@nongnu.org; Wed, 02 Dec 2009 07:22:59 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1NFoEP-0007tc-PR
	for qemu-devel@nongnu.org; Wed, 02 Dec 2009 07:22:57 -0500
Received: from [199.232.76.173] (port=50029 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1NFoEP-0007tN-Cn
	for qemu-devel@nongnu.org; Wed, 02 Dec 2009 07:22:53 -0500
Received: from mx1.redhat.com ([209.132.183.28]:58332)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <gleb@redhat.com>) id 1NFoEO-0006A6-S3
	for qemu-devel@nongnu.org; Wed, 02 Dec 2009 07:22:53 -0500
Date: Wed, 2 Dec 2009 14:22:50 +0200
From: Gleb Natapov <gleb@redhat.com>
Message-ID: <20091202122250.GC9537@redhat.com>
References: <1259671897-22232-1-git-send-email-glommer@redhat.com>
	<20091202105927.GB9537@redhat.com> <4B1657C0.20104@siemens.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4B1657C0.20104@siemens.com>
Subject: [Qemu-devel] Re: [PATCH v2 0/11]
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Jan Kiszka <jan.kiszka@siemens.com>
Cc: qemu-devel@nongnu.org, Glauber Costa <glommer@redhat.com>, avi@redhat.com, agraf@suse.de, aliguori@us.ibm.com

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.

--
			Gleb.