From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46124) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a6hZs-0004tM-TV for qemu-devel@nongnu.org; Wed, 09 Dec 2015 11:26:53 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a6hZo-0006WK-Pb for qemu-devel@nongnu.org; Wed, 09 Dec 2015 11:26:52 -0500 Received: from mga09.intel.com ([134.134.136.24]:9352) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a6hZo-0006Vn-Ia for qemu-devel@nongnu.org; Wed, 09 Dec 2015 11:26:48 -0500 References: <1448372127-28115-1-git-send-email-tianyu.lan@intel.com> <20151207165039.GA20210@redhat.com> From: "Lan, Tianyu" Message-ID: <56685631.50700@intel.com> Date: Thu, 10 Dec 2015 00:26:25 +0800 MIME-Version: 1.0 In-Reply-To: <20151207165039.GA20210@redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] live migration vs device assignment (motivation) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: qemu-devel@nongnu.org, emil.s.tantilov@intel.com, kvm@vger.kernel.org, ard.biesheuvel@linaro.org, aik@ozlabs.ru, donald.c.skidmore@intel.com, quintela@redhat.com, eddie.dong@intel.com, nrupal.jani@intel.com, agraf@suse.de, blauwirbel@gmail.com, cornelia.huck@de.ibm.com, alex.williamson@redhat.com, kraxel@redhat.com, anthony@codemonkey.ws, amit.shah@redhat.com, pbonzini@redhat.com, mark.d.rustad@intel.com, lcapitulino@redhat.com, gerlitz.or@gmail.com On 12/8/2015 12:50 AM, Michael S. Tsirkin wrote: > I thought about what this is doing at the high level, and I do have some > value in what you are trying to do, but I also think we need to clarify > the motivation a bit more. What you are saying is not really what the > patches are doing. > > And with that clearer understanding of the motivation in mind (assuming > it actually captures a real need), I would also like to suggest some > changes. Motivation: Most current solutions for migration with passthough device are based on the PCI hotplug but it has side affect and can't work for all device. For NIC device: PCI hotplug solution can work around Network device migration via switching VF and PF. But switching network interface will introduce service down time. I tested the service down time via putting VF and PV interface into a bonded interface and ping the bonded interface during plug and unplug VF. 1) About 100ms when add VF 2) About 30ms when del VF It also requires guest to do switch configuration. These are hard to manage and deploy from our customers. To maintain PV performance during migration, host side also needs to assign a VF to PV device. This affects scalability. These factors block SRIOV NIC passthough usage in the cloud service and OPNFV which require network high performance and stability a lot. For other kind of devices, it's hard to work. We are also adding migration support for QAT(QuickAssist Technology) device. QAT device user case introduction. Server, networking, big data, and storage applications use QuickAssist Technology to offload servers from handling compute-intensive operations, such as: 1) Symmetric cryptography functions including cipher operations and authentication operations 2) Public key functions including RSA, Diffie-Hellman, and elliptic curve cryptography 3) Compression and decompression functions including DEFLATE and LZS PCI hotplug will not work for such devices during migration and these operations will fail when unplug device. So we are trying implementing a new solution which really migrates device state to target machine and won't affect user during migration with low service down time.