From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: [RFC PATCH V2 00/10] Qemu: Add live migration support for SRIOV NIC Date: Mon, 30 Nov 2015 10:01:18 +0200 Message-ID: <20151130095454-mutt-send-email-mst@redhat.com> References: <1448372127-28115-1-git-send-email-tianyu.lan@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: aik@ozlabs.ru, alex.williamson@redhat.com, amit.shah@redhat.com, anthony@codemonkey.ws, ard.biesheuvel@linaro.org, blauwirbel@gmail.com, cornelia.huck@de.ibm.com, eddie.dong@intel.com, nrupal.jani@intel.com, agraf@suse.de, kvm@vger.kernel.org, pbonzini@redhat.com, qemu-devel@nongnu.org, emil.s.tantilov@intel.com, gerlitz.or@gmail.com, donald.c.skidmore@intel.com, mark.d.rustad@intel.com, kraxel@redhat.com, lcapitulino@redhat.com, quintela@redhat.com To: Lan Tianyu Return-path: Received: from mx1.redhat.com ([209.132.183.28]:38322 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752886AbbK3IBZ (ORCPT ); Mon, 30 Nov 2015 03:01:25 -0500 Content-Disposition: inline In-Reply-To: <1448372127-28115-1-git-send-email-tianyu.lan@intel.com> Sender: kvm-owner@vger.kernel.org List-ID: On Tue, Nov 24, 2015 at 09:35:17PM +0800, Lan Tianyu wrote: > This patchset is to propose a solution of adding live migration > support for SRIOV NIC. > > During migration, Qemu needs to let VF driver in the VM to know > migration start and end. Qemu adds faked PCI migration capability > to help to sync status between two sides during migration. > > Qemu triggers VF's mailbox irq via sending MSIX msg when migration > status is changed. VF driver tells Qemu its mailbox vector index > via the new PCI capability. In some cases(NIC is suspended or closed), > VF mailbox irq is freed and VF driver can disable irq injecting via > new capability. > > VF driver will put down nic before migration and put up again on > the target machine. It is still not very clear what it is you are trying to achieve, and whether your patchset achieves it. You merely say "adding live migration" but it seems pretty clear this isn't about being able to migrate a guest transparently, since you are adding a host/guest handshake. This isn't about functionality either: I think that on KVM, it isn't hard to live migrate if you can do a host/guest handshake, even today, with no kernel changes: 1. before migration, expose a pv nic to guest (can be done directly on boot) 2. use e.g. a serial connection to move IP from an assigned device to pv nic 3. maybe move the mac as well 4. eject the assigned device 5. detect eject on host (QEMU generates a DEVICE_DELETED event when this happens) and start migration Is this patchset a performance optimization then? If yes it needs to be accompanied with some performance numbers. -- MST