From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: [Qemu-devel] live migration vs device assignment (motivation) Date: Mon, 28 Dec 2015 13:50:27 +0200 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-Transfer-Encoding: QUOTED-PRINTABLE Cc: Alexander Duyck , "Lan, Tianyu" , "Dr. David Alan Gilbert" , Yang Zhang , "qemu-devel@nongnu.org" , "Tantilov, Emil S" , "kvm@vger.kernel.org" , Ard Biesheuvel , "aik@ozlabs.ru" , "Skidmore, Donald C" , "quintela@redhat.com" , "Jani, Nrupal" , Alexander Graf , Blue Swirl , "cornelia.huck@de.ibm.com" , Alex Williamson , "kraxel@redhat.com" , Anthony Liguori , "amit.shah@redhat.com" , Paolo Bonzini , "Rustad, Mark D" To: "Dong, Eddie" Return-path: Received: from mx1.redhat.com ([209.132.183.28]:33196 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751381AbbL1Lug (ORCPT ); Mon, 28 Dec 2015 06:50:36 -0500 Content-Disposition: inline In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On Mon, Dec 28, 2015 at 03:20:10AM +0000, Dong, Eddie wrote: > > > > > > Even if the device driver doesn't support migration, you still wa= nt to > > > migrate VM? That maybe risk and we should add the "bad path" for = the > > > driver at least. > >=20 > > At a minimum we should have support for hot-plug if we are expectin= g to > > support migration. You would simply have to hot-plug the device be= fore you > > start migration and then return it after. That is how the current = bonding > > 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 fo= r 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 t= o 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= the > > device for as long as possible. Ideally we want to keep the device= active > > through the warm-up period, but if the guest doesn't do that we sho= uld still > > be able to fall back on the older approaches if needed. > >=20