On Fri, 7 Apr 2023 15:47:10 +0000 "Liu, Yi L" <yi.l.liu@xxxxxxxxx> wrote: > > From: Alex Williamson <alex.williamson@xxxxxxxxxx> > > Sent: Friday, April 7, 2023 11:14 PM > > > > On Fri, 7 Apr 2023 14:04:02 +0000 > > "Liu, Yi L" <yi.l.liu@xxxxxxxxx> wrote: > > > > > > From: Alex Williamson <alex.williamson@xxxxxxxxxx> > > > > Sent: Friday, April 7, 2023 9:52 PM > > > > > > > > On Fri, 7 Apr 2023 13:24:25 +0000 > > > > "Liu, Yi L" <yi.l.liu@xxxxxxxxx> wrote: > > > > > > > > > > From: Alex Williamson <alex.williamson@xxxxxxxxxx> > > > > > > Sent: Friday, April 7, 2023 8:04 PM > > > > > > > > > > > > > > > > @@ -791,7 +813,21 @@ static int vfio_pci_fill_devs(struct pci_dev > > *pdev, > > > > void > > > > > > > > *data) > > > > > > > > > > if (!iommu_group) > > > > > > > > > > return -EPERM; /* Cannot reset non-isolated devices */ > > > > > > > > > > [1] > > > > > > > > > > > > > > > > > > > > > > > Hi Alex, > > > > > > > > > > > > > > > > > > Is disabling iommu a sane way to test vfio noiommu mode? > > > > > > > > > > > > > > > > Yes > > > > > > > > > > > > > > > > > I added intel_iommu=off to disable intel iommu and bind a device to vfio- > > pci. > > > > > > > > > I can see the /dev/vfio/noiommu-0 and /dev/vfio/devices/noiommu-vfio0. > > > > Bind > > > > > > > > > iommufd==-1 can succeed, but failed to get hot reset info due to the > > above > > > > > > > > > group check. Reason is that this happens to have some affected devices, > > and > > > > > > > > > these devices have no valid iommu_group (because they are not bound to > > > > vfio- > > > > > > pci > > > > > > > > > hence nobody allocates noiommu group for them). So when hot reset info > > > > loops > > > > > > > > > such devices, it failed with -EPERM. Is this expected? > > > > > > > > > > > > > > > > Hmm, I didn't recall that we put in such a limitation, but given the > > > > > > > > minimally intrusive approach to no-iommu and the fact that we never > > > > > > > > defined an invalid group ID to return to the user, it makes sense that > > > > > > > > we just blocked the ioctl for no-iommu use. I guess we can do the same > > > > > > > > for no-iommu cdev. > > > > > > > > > > > > > > I just realize a further issue related to this limitation. Remember that we > > > > > > > may finally compile out the vfio group infrastructure in the future. Say I > > > > > > > want to test noiommu, I may boot such a kernel with iommu disabled. I think > > > > > > > the _INFO ioctl would fail as there is no iommu_group. Does it mean we will > > > > > > > not support hot reset for noiommu in future if vfio group infrastructure is > > > > > > > compiled out? > > > > > > > > > > > > We're talking about IOMMU groups, IOMMU groups are always present > > > > > > regardless of whether we expose a vfio group interface to userspace. > > > > > > Remember, we create IOMMU groups even in the no-iommu case. Even with > > > > > > pure cdev, there are underlying IOMMU groups that maintain the DMA > > > > > > ownership. > > > > > > > > > > hmmm. As [1], when iommu is disabled, there will be no iommu_group for a > > > > > given device unless it is registered to VFIO, which a fake group is created. > > > > > That's why I hit the limitation [1]. When vfio_group is compiled out, then > > > > > even fake group goes away. > > > > > > > > In the vfio group case, [1] can be hit with no-iommu only when there > > > > are affected devices which are not bound to vfio. > > > > > > yes. because vfio would allocate fake group when device is registered to > > > it. > > > > > > > Why are we not > > > > allocating an IOMMU group to no-iommu devices when vfio group is > > > > disabled? Thanks, > > > > > > hmmm. when the vfio group code is configured out. The > > > vfio_device_set_group() just returns 0 after below patch is > > > applied and CONFIG_VFIO_GROUP=n. So when there is no > > > vfio group, the fake group also goes away. > > > > > > https://lore.kernel.org/kvm/20230401151833.124749-25-yi.l.liu@xxxxxxxxx/ > > > > Is this a fundamental issue or just a problem with the current > > implementation proposal? It seems like the latter. FWIW, I also don't > > see a taint happening in the cdev path for no-iommu use. Thanks, > > yes. the latter case. The reason I raised it here is to confirm the > policy on the new group/bdf capability in the DEVICE_GET_INFO. If > there is no iommu group, perhaps I only need to exclude the new > group/bdf capability from the cap chain of DEVICE_GET_INFO. is it? I think we need to revisit the question of why allocating an IOMMU group for a no-iommu device is exclusive to the vfio group support. We've already been down the path of trying to report a field that only exists for devices with certain properties with dev-id. It doesn't work well. I think we've said all along that while the cdev interface is device based, there are still going to be underlying IOMMU groups for the user to be aware of, they're just not as much a fundamental part of the interface. There should not be a case where a device doesn't have a group to report. Thanks, Alex
