[libvirt] [PATCH v4 0/5] PCI hostdev partial assignment support
Alex Williamson
alex.williamson at redhat.com
Mon Dec 16 23:43:07 UTC 2019
On Mon, 16 Dec 2019 20:24:56 -0300
Daniel Henrique Barboza <danielhb413 at gmail.com> wrote:
> On 12/16/19 8:06 PM, Alex Williamson wrote:
> > On Mon, 16 Dec 2019 17:28:28 -0500
> > Cole Robinson <crobinso at redhat.com> wrote:
> >
> >> On 12/16/19 8:36 AM, Daniel Henrique Barboza wrote:
> >>> changes from version 3 [1]:
> >
> > Thanks for catching this! PCIe root ports or bridges being part of an
> > IOMMU group is part of the nature of the grouping. However, only
> > endpoint devices can be bound to vfio-pci and thus participate in this
> > "partial assignment". If the code is trying to force all other devices
> > in the IOMMU group that aren't assigned into this partial assignment
> > mode, that's just fundamentally broken. Thanks,
>
> The code isn't forcing a device to be assigned to the guest. It is forcing
> all the IOMMU devices to be declared in the domain XML to be detached from
> the host.
Detached from the host by unbinding from host drivers and binding to
vfio-pci and "partially" assigned to the guest? That's wrong, we can't
do that. Not only will vfio-pci not bind to anything but endpoints,
you'll break the host binding bridges that might be part of the group,
and there are valid use cases for sequestering a device with pci-stub
rather than vfio-pci to add another barrier to the user getting access
to the device.
> What I did was to extend a verification Libvirt already does, to check for
> PCI devices of the same IOMMU X being used by other domains, to check the
> the host as well. Guest start fails if there is any device left in IOMMU X
> that's not present in the domain.
Yep, can't do that.
> In short, the code is implying that all IOMMU devices must be detached from
> the host, regardless of whether they're going to be used in the guest,
> regardless of whether they are PCI root ports or bridges. Is this assumption
> correct, considering kernel/QEMU?
Nope, please don't do this. Thanks,
Alex
More information about the libvir-list
mailing list