From mboxrd@z Thu Jan 1 00:00:00 1970 From: Juan Quintela Subject: Re: [RFC] New thread for the VM migration Date: Thu, 14 Jul 2011 17:30:28 +0200 Message-ID: References: <1447945249.1317755.1310627692984.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> <4E1EAA72.1060103@redhat.com> <4E1EE183.5050100@codemonkey.ws> <4E1EE1F2.5020801@redhat.com> Reply-To: quintela@redhat.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Anthony Liguori , Umesh Deshpande , qemu-devel@nongnu.org, kvm@vger.kernel.org To: Avi Kivity Return-path: Received: from mx1.redhat.com ([209.132.183.28]:51030 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754724Ab1GNPb7 (ORCPT ); Thu, 14 Jul 2011 11:31:59 -0400 In-Reply-To: <4E1EE1F2.5020801@redhat.com> (Avi Kivity's message of "Thu, 14 Jul 2011 15:32:50 +0300") Sender: kvm-owner@vger.kernel.org List-ID: Avi Kivity wrote: > On 07/14/2011 03:30 PM, Anthony Liguori wrote: >>> Does this mean that the following code is sometimes executed without >>> qemu_mutex? I don't think any of it is thread safe. >> >> >> That was my reaction too. >> >> I think the most rational thing to do is have a separate thread and >> a pair of producer/consumer queues. >> >> The I/O thread can push virtual addresses and sizes to the queue for >> the migration thread to compress/write() to the fd. The migration >> thread can then push sent regions onto a separate queue for the I/O >> thread to mark as dirty. > > Even virtual addresses are not safe enough, because of hotunplug. > Without some kind of locking, you have to copy the data. Disabling hotplug should be enough? Notice that hotplug/unplug during migration don't make a lot of sense anyways. Not all the bitmap syncying has proper locking now (copyng towards one place), but rest of cade looks really thread safe to me (migration code is only called from this thread, so it should be safe). My understanding on how this work: vcpu thread modifies momery iothread (some times) modifies memory migration thread: reads memory, and gets the lock before syncing its bitmap with kvm one and qemu one (clearing it on the time). Assume we disable hotplug/unplug (what we have to do anyways). What is the locking problem that we have? We do stage 3 with the iothread locked, i.e. at that point everything else is stopped. Before stage 3, can kvm or qemu modify a page and _not_ modify the bitmap? My understanding is not. Only real variable that we are sharing is ram_list, or I am losing something obvious? Later, Juan.