[libvirt] [PATCH 00/10] VFIO fixes for PCI devices

Alex Williamson alex.williamson at redhat.com
Thu Dec 10 15:41:04 UTC 2015


On Thu, 2015-12-10 at 09:06 +0100, Andrea Bolognani wrote:
> On Wed, 2015-12-09 at 08:09 -0700, Alex Williamson wrote:
> > > I was under the impression that what the current series
> > > does, eg. sharing devices in the same IOMMU group between
> > > the host driver and vfio-pci is safe as long as no guest is
> > > using them at the same time, and that devices could be
> > > safely "moved" between the host driver (eg. in use) and
> > > vfio-pci (eg. idle, waiting to be assigned to a guest) as
> > > many times as desired without ill consequences.
> > > 
> > > Is my understanding wrong? Do I need to rework the series
> > > so that unbinds and reprobes are always executed across the
> > > IOMMU group?
> > 
> > Hi Andrea,
> > 
> > Your understanding is correct, so I think it just comes down to how sure
> > you are that the vfio group is idle/unused.  If there's any risk that a
> > device is still in use by QEMU, then we haven't solved the original
> > problem.  Unbinding isn't the only way to have good confidence of this
> > though.  You could track the QEMU pid, you could use fuser to make sure
> > the group is not in use, you could try to open the group yourself to
> > make sure it's not in use, and of course you can unbind as proposed in
> > the second option.  So long as you know the group is idle, somehow, it
> > shouldn't matter what order you unbind and reprobe.
> 
> Thanks for the confirmation, Alex.
> 
> What we're doing right now in libvirt (and my series extends on that)
> is keeping track of each device's state internally by recording
> information such as which guest, if any, is using it.
> 
> We're mostly assuming that the user will not mess with the configuration
> behind our back. I guess adding more checks to make sure that's actually
> the case would be good, but then again, we can hardly stop the user from
> writing stuff into /sys :)
> 
> At least now we know my series is not built upon a completely incorrect
> understanding of the constraints!
> 
> Quick follow-up question: all of this care with IOMMU group ownership is
> only really applied when dealing with VFIO passthrough - are legacy KVM
> assignment and Xen assignment really not affected at all? Is the IOMMU
> not involved in the process?

Both legacy KVM device assignment and (afaik) Xen device assignment
ignore the issues of device isolation, and typically even iommu
granularity, and allow any configuration imaginable, even when it
interferes with the operation of devices owned by other guests or even
host-owned devices.  Thanks,

Alex




More information about the libvir-list mailing list