[Intel-gfx] [PATCH v3 05/12] vfio/pci: Allow passing zero-length fd array in VFIO_DEVICE_PCI_HOT_RESET
Alex Williamson
alex.williamson at redhat.com
Wed Apr 5 15:36:46 UTC 2023
On Wed, 5 Apr 2023 08:01:49 +0000
"Liu, Yi L" <yi.l.liu at intel.com> wrote:
> > From: Liu, Yi L <yi.l.liu at intel.com>
> > Sent: Wednesday, April 5, 2023 3:55 PM
>
> > >
> > > Therefore, I think as written, the singleton dev_set hot-reset is
> > > enabled for iommufd and (unintentionally?) for the group path, while
> > > also negating a requirement for a group fd or that a provided group fd
> > > actually matches the device in this latter case. The null-array
> > > approach is not however extended to groups for more general use.
> > > Additionally, limiting no-iommu hot-reset to singleton dev_sets
> > > provides only a marginal functional difference vs VFIO_DEVICE_RESET.
> >
> > I think the singletion dev_set hot-reset is for iommufd (or more accurately
> > for the noiommu case in cdev path).
>
> but actually, singleton dev_set hot-reset can work for group path as well.
> Based on this, I'm also wondering do we really want to have singleton dev_set
> hot-reset only for cdev noiommu case? or we allow it generally or just
> don't support it as it is equivalent with VFIO_DEVICE_RESET?
I think you're taking the potential that VFIO_DEVICE_RESET and
hot-reset could do the same thing too far. The former is more likely
to do an FLR, or even a PM reset. QEMU even tries to guess what reset
VFIO_DEVICE_RESET might use in order to choose to do a hot-reset if it
seems like the device might only support a PM reset otherwise.
Changing the reset method of a device requires privilege, which is
maybe something we'd compromise on for no-iommu, but the general
expectation is that VFIO_DEVICE_RESET provides a device level scope and
hot-reset provides a... hot-reset, and sometimes those are the same
thing, but that doesn't mean we can lean on the former.
> If we don't support singletion dev_set hot-reset, noiommu devices in cdev
> path shall fail the hot-reset if empty-fd array is provided. But we may just
> document that empty-fd array does not work for noiommu. User should
> use the device fd array.
I don't see any replies to my comment on 08/12 where I again question
why we need an empty array option. It's causing all sorts of headaches
and I don't see the justification for it beyond some hand waving that
it reduces complexity for the user. This singleton dev-set notion
seems equally unjustified. Do we just need to deal with hot-reset
being unsupported for no-iommu devices with iommufd? Thanks,
Alex
More information about the Intel-gfx
mailing list