Re: [PATCH v4 00/10] Few VFIO related fixes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, 2015-11-14 at 14:03 +0530, Shivaprasad G Bhat wrote:
> The series fixes few VFIO related host crash issues. The patches 3, 4, 9 and 10
> are actual fixes. Patch 7 and 8 are test changes to allow testing patch 9.
> Rest of the patches are mostly code movements except for patch 2.
> 
> ---
> Changes from v3 -> v4
>       - Andrea's suggestion not to overload the usage of stubDriver to set it in
>         virPCINew is addressed. Not setting it any more. Fetch it fresh from
>         sysfs.
>       - The test case added in old P7 is improvised
>       - Old P7 is split into 3 patches where I have moved the virpcimock
>         changes to support iommu into a new patch.
> 
> Shivaprasad G Bhat (10):
>       Implement virPCIIsKnownStub function
>       Add iommu group number info to virPCIDevice
>       Refuse to reattach from vfio if the iommu group is in use by any domain
>       Wait for vfio-pci device cleanups before reassinging the device to host driver
>       Split reprobe action from the virPCIUnbindFromStub into a new function
>       Pass activeDevs and inactiveDevs to virPCIDeviceUnbindFromStub and virPCIDeviceBindToStub
>       Change the negative test case to try pciback instead of vfio-pci
>       Add iommu info for pci on mocked sysfs
>       Postpone reprobing till all the devices in iommu group are unbound from vfio
>       Wait for iommmu device to go away before reprobing the host driver
> 
> 
>  src/util/virhostdev.c |   28 ++++-
>  src/util/virpci.c     |  297 +++++++++++++++++++++++++++++++++++++++++--------
>  tests/virpcimock.c    |  193 +++++++++++++++++++++++++++++---
>  tests/virpcitest.c    |  117 +++++++++++++++++++
>  4 files changed, 566 insertions(+), 69 deletions(-)

I haven't gone through the patches, but I've tried detaching
one of the four functions of an Ethernet adapter while the
guest was running and I haven't experienced the host crash
doing so usually leads to.

I will look at the code tomorrow to report issues and
weak-ACK what looks okay; a more authoritative second
opinion is definitely needed before any of this can go in.

Cheers.

-- 
Andrea Bolognani
Software Engineer - Virtualization Team

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]