On Mon, 16 Dec 2019 20:24:56 -0300 Daniel Henrique Barboza <danielhb413@xxxxxxxxx> wrote: > On 12/16/19 8:06 PM, Alex Williamson wrote: > > On Mon, 16 Dec 2019 17:28:28 -0500 > > Cole Robinson <crobinso@xxxxxxxxxx> 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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
