> From: Liu, Yi L <yi.l.liu@xxxxxxxxx>
> Sent: Thursday, September 12, 2024 9:17 PM
>
> +/*
> + * VFIO_DEVICE_PASID_ATTACH_IOMMUFD_PT - _IOW(VFIO_TYPE,
> VFIO_BASE + 21,
> + * struct
> vfio_device_pasid_attach_iommufd_pt)
> + * @argsz: User filled size of this data.
> + * @flags: Must be 0.
> + * @pasid: The pasid to be attached.
> + * @pt_id: Input the target id which can represent an ioas or a hwpt
> + * allocated via iommufd subsystem.
> + * Output the input ioas id or the attached hwpt id which could
> + * be the specified hwpt itself or a hwpt automatically created
> + * for the specified ioas by kernel during the attachment.
> + *
> + * Associate a pasid with an address space within the bound iommufd.
> Undo by
> + * VFIO_DEVICE_PASID_DETACH_IOMMUFD_PT or device fd close. This is
> only allowed
> + * on cdev fds.
> + *
> + * If a pasid is currently attached to a valid hwpt, without doing a
> + * VFIO_DEVICE_PASID_DETACH_IOMMUFD_PT, a second
> + * VFIO_DEVICE_PASID_ATTACH_IOMMUFD_PT ioctl passing in another
> hwpt id is
> + * allowed. This action, also known as a hwpt replacement, will replace the
> + * pasid's currently attached hwpt with a new hwpt corresponding to the
> given
> + * @pt_id.
> + *
> + * Return: 0 on success, -errno on failure.
> + */
> +struct vfio_device_pasid_attach_iommufd_pt {
> + __u32 argsz;
> + __u32 flags;
> + __u32 pasid;
> + __u32 pt_id;
> +};
> +
> +#define VFIO_DEVICE_PASID_ATTACH_IOMMUFD_PT _IO(VFIO_TYPE,
> VFIO_BASE + 21)
Not sure whether this was discussed before. Does it make sense
to reuse the existing VFIO_DEVICE_ATTACH_IOMMUFD_PT
by introducing a new pasid field and a new flag bit?
