> From: Jason Gunthorpe <jgg@xxxxxxxxxx>
> Sent: Thursday, April 13, 2023 4:07 AM
>
>
> > in which case we need c) a way to
> > report the overall set of affected devices regardless of ownership in
> > support of 4), BDF?
>
> Yes, continue to use INFO unmodified.
>
> > Are we back to replacing group-ids with dev-ids in the INFO structure,
> > where an invalid dev-id either indicates an affected device with
> > implied ownership (ok) or a gap in ownership (bad) and a flag somewhere
> > is meant to indicate the overall disposition based on the availability
> > of reset?
>
> As you explore in the following this gets ugly. I prefer to keep INFO
> unchanged and add INFO2.
>
INFO needs a change when VFIO_GROUP is disabled. Now it assumes
a valid iommu group always exists:
vfio_pci_fill_devs()
{
...
iommu_group = iommu_group_get(&pdev->dev);
if (!iommu_group)
return -EPERM; /* Cannot reset non-isolated devices */
...
}
Probably we need a special value e.g. -1 to represent noiommu case
given valid group ids are positive.
with that plus BDF cap, I'm curious what is the actual purpose of
INFO2 or why cannot requirement#3 reuse the information collected
via existing INFO?
For each opened device Qemu can find the related group id via
sysfs (if group exists) or an optional GROUP cap and use that id to
match the group id in INFO.
For noiommu it has a group id if VFIO_GROUP=y then same case.
For noiommu if VFIO_GROUP=n just do exact match based on BDF.
Either way the information returned by INFO is a superset of knowing
the reset scope between opened devices.
Thanks
Kevin
