[Intel-gfx] [PATCH v6 09/10] vfio/pci: Extend VFIO_DEVICE_GET_PCI_HOT_RESET_INFO for vfio device cdev
Liu, Yi L
yi.l.liu at intel.com
Thu May 25 13:02:04 UTC 2023
> From: Alex Williamson <alex.williamson at redhat.com>
> Sent: Thursday, May 25, 2023 3:56 AM
> On Mon, 22 May 2023 04:57:50 -0700
> Yi Liu <yi.l.liu at intel.com> wrote:
>
> > +
> > +/*
> > + * Return devid for vfio_device if the device is owned by the input
> > + * ictx.
> > + * - valid devid > 0 for the device that are bound to the input
> > + * iommufd_ctx.
> > + * - devid == VFIO_PCI_DEVID_OWNED for the devices that have not
> > + * been opened but but other device within its group has been
>
> "but but"
Thanks for catching it.
>
> > + * bound to the input iommufd_ctx.
> > + * - devid == VFIO_PCI_DEVID_NOT_OWNED for others. e.g. vdev is
> > + * NULL.
> > + */
> > +int vfio_iommufd_device_hot_reset_devid(struct vfio_device *vdev,
> > + struct iommufd_ctx *ictx)
> > +{
> > + struct iommu_group *group;
> > + int devid;
> > +
> > + if (!vdev)
> > + return VFIO_PCI_DEVID_NOT_OWNED;
> > +
> > + if (vfio_iommufd_device_ictx(vdev) == ictx)
> > + return vfio_iommufd_device_id(vdev);
> > +
> > + group = iommu_group_get(vdev->dev);
> > + if (!group)
> > + return VFIO_PCI_DEVID_NOT_OWNED;
> > +
> > + if (iommufd_ctx_has_group(ictx, group))
> > + devid = VFIO_PCI_DEVID_OWNED;
> > + else
> > + devid = VFIO_PCI_DEVID_NOT_OWNED;
> > +
> > + iommu_group_put(group);
> > +
> > + return devid;
> > +}
> > --- a/include/uapi/linux/vfio.h
> > +++ b/include/uapi/linux/vfio.h
> > @@ -650,11 +650,53 @@ enum {
> > * VFIO_DEVICE_GET_PCI_HOT_RESET_INFO - _IOWR(VFIO_TYPE, VFIO_BASE + 12,
> > * struct vfio_pci_hot_reset_info)
> > *
> > + * This command is used to query the affected devices in the hot reset for
> > + * a given device.
> > + *
> > + * This command always reports the segment, bus, and devfn information for
> > + * each affected device, and selectively reports the group_id or devid per
> > + * the way how the calling device is opened.
> > + *
> > + * - If the calling device is opened via the traditional group/container
> > + * API, group_id is reported. User should check if it has owned all
> > + * the affected devices and provides a set of group fds to prove the
> > + * ownership in VFIO_DEVICE_PCI_HOT_RESET ioctl.
> > + *
> > + * - If the calling device is opened as a cdev, devid is reported.
> > + * Flag VFIO_PCI_HOT_RESET_FLAG_DEV_ID is set to indicate this
> > + * data type. For a given affected device, it is considered owned by
> > + * this interface if it meets the following conditions:
> > + * 1) Has a valid devid within the iommufd_ctx of the calling device.
> > + * Ownership cannot be determined across separate iommufd_ctx and the
> > + * cdev calling conventions do not support a proof-of-ownership model
> > + * as provided in the legacy group interface. In this case a valid
> > + * devid with value greater than zero is provided in the return
> > + * structure.
> > + * 2) Does not have a valid devid within the iommufd_ctx of the calling
> > + * device, but belongs to the same IOMMU group as the calling device
> > + * or another opened device that has a valid devid within the
> > + * iommufd_ctx of the calling device. This provides implicit ownership
> > + * for devices within the same DMA isolation context. In this case
> > + * the invalid devid value of zero is provided in the return structure.
> > + *
> > + * A devid value of -1 is provided in the return structure for devices
>
> s/zero/VFIO_PCI_DEVID_OWNED/
>
> s/-1/VFIO_PCI_DEVID_NOT_OWNED/
Will do.
> 2) above and previously in the code comment where I noted the repeated
> "but" still doesn't actually describe the requirement as I noted in the
> last review. The user implicitly owns a device if they own another
> device within the IOMMU group, but we also impose a dev_set requirement
> in the hot reset path. All affected devices need to be represented in
> the dev_set, ex. bound to a vfio driver.
Yes. it is. Btw. dev_set is not visible to user. Is it good to mention it
in uapi header especially w.r.t. the below potential relaxing of this
requirement?
> It's possible that requirement
> might be relaxed in the new DMA ownership model, but as it is right
> now, the code enforces that requirement and any new discussion about
> what makes hot-reset available should note both the ownership and
> dev_set requirement. Thanks,
I think your point is that if an iommufd_ctx has acquired DMA ownerhisp
of an iommu_group, it means the device is owned. And it should not
matter whether all the devices in the iommu_group is present in the
dev_set. It is allowed that some devices are bound to pci-stub or
pcieport driver. Is it?
Actually I have a doubt on it. IIUC, the above requirement on dev_set
is to ensure the reset to the devices are protected by the dev_set->lock.
So that either the reset issued by driver itself or a hot reset request
from user, there is no race. But if a device is not in the dev_set, then
hot reset request from user might race with the bound driver. DMA ownership
only guarantees the drivers won't handle DMA via DMA API which would have
conflict with DMA mappings from user. I'm not sure if it is able to
guarantee reset is exclusive as well. I see pci-stub and pcieport driver
are the only two drivers that set the driver_managed_dma flag besides the
vfio drivers. pci-stub may be fine. not sure about pcieport driver.
# line filename / context / line
1 39 drivers/pci/pci-stub.c <<GLOBAL>>
.driver_managed_dma = true,
2 796 drivers/pci/pcie/portdrv.c <<GLOBAL>>
.driver_managed_dma = true,
3 607 drivers/vfio/fsl-mc/vfio_fsl_mc.c <<GLOBAL>>
.driver_managed_dma = true,
4 1459 drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c <<GLOBAL>>
.driver_managed_dma = true,
5 1374 drivers/vfio/pci/mlx5/main.c <<GLOBAL>>
.driver_managed_dma = true,
6 203 drivers/vfio/pci/vfio_pci.c <<GLOBAL>>
.driver_managed_dma = true,
7 139 drivers/vfio/platform/vfio_amba.c <<GLOBAL>>
.driver_managed_dma = true,
8 120 drivers/vfio/platform/vfio_platform.c <<GLOBAL>>
.driver_managed_dma = true,
Anyhow, I think this is not a must so far. is it? Even doable, it shall
be done in the future. :-)
Regards,
Yi Liu
More information about the Intel-gfx
mailing list