On Sat, 2015-11-14 at 14:06 +0530, Shivaprasad G Bhat wrote:
> Before unbind from stub driver libvirt should be sure the guest is not using
> the device anymore. The libvirt today waits for pci-stub driver alone in /proc/iommu.
> The same wait is needed for vfio devices too.
>
> Signed-off-by: Shivaprasad G Bhat <sbhat@xxxxxxxxxxxxxxxxxx>
> ---
> src/util/virhostdev.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/src/util/virhostdev.c b/src/util/virhostdev.c
> index f24ccd8..9f15f34 100644
> --- a/src/util/virhostdev.c
> +++ b/src/util/virhostdev.c
> @@ -756,6 +756,13 @@ virHostdevReattachPCIDevice(virPCIDevicePtr dev, virHostdevManagerPtr mgr)
> usleep(100*1000);
> retries--;
> }
> + } else if (STREQ(virPCIDeviceGetStubDriver(dev), "vfio-pci")) {
> + int retries = 100;
> + while (virPCIDeviceWaitForCleanup(dev, "vfio-pci")
> + && retries) {
> + usleep(100*1000);
> + retries--;
> + }
> }
>
> if (virPCIDeviceReattach(dev, mgr->activePCIHostdevs,
Hi,
Laine pointed out this patch to me, and it seems entirely unnecessary.
Can you explain what it fixes?
The reason that pci-stub and legacy KVM device assignment needs to do
this little delay is because pci-stub itself is not in control of the
device, it will happily release the device at any point in time,
regardless of whether KVM is still making use of it. With vfio-pci, all
the device access occurs through the vfio-pci driver, so you can be sure
that if the vfio-pci driver unbinds from the device it is unused. In
fact, the unbind will block until it is unused.
Are you doing this to make sure you don't get stuck in that blocked
unbind and trigger an eject request to the guest? It certainly needs an
explanation beyond pci-stub did this, so we should too. Thanks,
Alex
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list