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]: > > - removed last 2 patches that made function 0 of > > PCI multifunction devices mandatory > > - new patch: news.xml update > > - changed 'since' version to 6.0.0 in patch 4 > > - unassigned hostdevs are now getting qemu aliases > > > > [1] https://www.redhat.com/archives/libvir-list/2019-November/msg01263.html > > > > Daniel Henrique Barboza (5): > > Introducing new address type='unassigned' for PCI hostdevs > > qemu: handle unassigned PCI hostdevs in command line > > virhostdev.c: check all IOMMU devs in virHostdevPreparePCIDevices > > formatdomain.html.in: document <address type='unassigned'/> > > news.xml: add address type='unassigned' entry > > > > Codewise it looks fine now. But I'm looking more closely at patch #3 and > realizing that it can explicitly reject a previously accepted VM config. > And indeed, now that I give it a test with my GPU passthrough setup, it > is rejecting my previosly working config. > > error: Requested operation is not valid: All devices of the same IOMMU > group 1 of the PCI device 0000:01:00.0 must belong to domain win10 > > I've attached the nodedev XML for the three devices with iommuGroup 1. > Only the two nvidia devices are assigned to my VM, but not the PCIe > controller device. > > Is the libvirt heuristic missing something? Or is this acting as expected? > > I didn't quite gather that this is a change to reject previously > accepted configurations, so I will defer to Laine and Alex as to whether > this should be committed. 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, Alex -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
