From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43599) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1cFN-0003ZG-1B for qemu-devel@nongnu.org; Wed, 25 Nov 2015 10:44:41 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a1cFJ-0004x0-3A for qemu-devel@nongnu.org; Wed, 25 Nov 2015 10:44:40 -0500 Received: from mx1.redhat.com ([209.132.183.28]:49433) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1cFI-0004wh-UA for qemu-devel@nongnu.org; Wed, 25 Nov 2015 10:44:37 -0500 Date: Wed, 25 Nov 2015 17:44:23 +0200 From: "Michael S. Tsirkin" Message-ID: <20151125174244-mutt-send-email-mst@redhat.com> References: <1448372127-28115-1-git-send-email-tianyu.lan@intel.com> <1448372127-28115-10-git-send-email-tianyu.lan@intel.com> <20151124225604-mutt-send-email-mst@redhat.com> <5655D487.6030400@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5655D487.6030400@intel.com> Subject: Re: [Qemu-devel] [RFC PATCH V2 09/10] Qemu/VFIO: Add SRIOV VF migration support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Lan, Tianyu" 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 Wed, Nov 25, 2015 at 11:32:23PM +0800, Lan, Tianyu wrote: > > On 11/25/2015 5:03 AM, Michael S. Tsirkin wrote: > >>>+void vfio_migration_cap_handle(PCIDevice *pdev, uint32_t addr, > >>>+ uint32_t val, int len) > >>>+{ > >>>+ VFIOPCIDevice *vdev = DO_UPCAST(VFIOPCIDevice, pdev, pdev); > >>>+ > >>>+ if (addr == vdev->migration_cap + PCI_VF_MIGRATION_VF_STATUS > >>>+ && val == PCI_VF_READY_FOR_MIGRATION) { > >>>+ qemu_event_set(&migration_event); > >This would wake migration so it can proceed - > >except it needs QEMU lock to run, and that's > >taken by the migration thread. > > Sorry, I seem to miss something. > Which lock may cause dead lock when calling vfio_migration_cap_handle() > and run migration? qemu_global_mutex. > The function is called when VF accesses faked PCI capability. > > > > >It seems unlikely that this ever worked - how > >did you test this? > >