From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59747) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aDWK3-0000iX-8Q for qemu-devel@nongnu.org; Mon, 28 Dec 2015 06:50:44 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aDWJy-0006HC-8m for qemu-devel@nongnu.org; Mon, 28 Dec 2015 06:50:43 -0500 Received: from mx1.redhat.com ([209.132.183.28]:38584) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aDWJy-0006H6-0y for qemu-devel@nongnu.org; Mon, 28 Dec 2015 06:50:38 -0500 Date: Mon, 28 Dec 2015 13:50:27 +0200 From: "Michael S. Tsirkin" Message-ID: <20151228115027.GA18063@redhat.com> References: <20151210101840.GA2570@work-vm> <566961C1.6030000@gmail.com> <20151210114114.GE2570@work-vm> <56698E68.5040207@intel.com> <566D9320.8000209@intel.com> <567CEA53.5030601@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] live migration vs device assignment (motivation) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Dong, Eddie" Cc: Yang Zhang , "Tantilov, Emil S" , "kvm@vger.kernel.org" , "aik@ozlabs.ru" , "qemu-devel@nongnu.org" , Alexander Duyck , "lcapitulino@redhat.com" , Blue Swirl , "kraxel@redhat.com" , "Rustad, Mark D" , "quintela@redhat.com" , "Skidmore, Donald C" , Alexander Graf , Or Gerlitz , "Dr. David Alan Gilbert" , Alex Williamson , Anthony Liguori , "cornelia.huck@de.ibm.com" , "Lan, Tianyu" , Ard Biesheuvel , "Jani, Nrupal" , "amit.shah@redhat.com" , Paolo Bonzini On Mon, Dec 28, 2015 at 03:20:10AM +0000, Dong, Eddie wrote: > > > > > > Even if the device driver doesn't support migration, you still want= to > > > migrate VM? That maybe risk and we should add the "bad path" for th= e > > > driver at least. > >=20 > > At a minimum we should have support for hot-plug if we are expecting = to > > support migration. You would simply have to hot-plug the device befo= re you > > start migration and then return it after. That is how the current bo= nding > > approach for this works if I am not mistaken. >=20 > Hotplug is good to eliminate the device spefic state clone, but > bonding approach is very network specific, it doesn=E2=80=99t work for = other > devices such as FPGA device, QaT devices & GPU devices, which we plan > to support gradually :) Alexander didn't say do bonding. He just said bonding uses hot-unplug. Gradual and generic is the correct approach. So focus on splitting the work into manageable pieces which are also useful by themselves, and generally reusable by different devices. So live the pausing alone for a moment. Start from Alexander's patchset for tracking dirty memory, add a way to control and detect it from userspace (and maybe from host), and a way to start migration while device is attached, removing it at the last possible moment. That will be a nice first step. > >=20 > > The advantage we are looking to gain is to avoid removing/disabling t= he > > device for as long as possible. Ideally we want to keep the device a= ctive > > through the warm-up period, but if the guest doesn't do that we shoul= d still > > be able to fall back on the older approaches if needed. > >=20