From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39911) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1c48-0003Hf-L7 for qemu-devel@nongnu.org; Wed, 25 Nov 2015 10:33:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a1c45-000200-8K for qemu-devel@nongnu.org; Wed, 25 Nov 2015 10:33:04 -0500 Received: from mga02.intel.com ([134.134.136.20]:63072) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1c45-0001yv-03 for qemu-devel@nongnu.org; Wed, 25 Nov 2015 10:33:01 -0500 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> From: "Lan, Tianyu" Message-ID: <5655D487.6030400@intel.com> Date: Wed, 25 Nov 2015 23:32:23 +0800 MIME-Version: 1.0 In-Reply-To: <20151124225604-mutt-send-email-mst@redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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: "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 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? The function is called when VF accesses faked PCI capability. > > It seems unlikely that this ever worked - how > did you test this? >