> From: Lu Baolu
> Sent: Sunday, April 28, 2024 11:20 AM
>
> A kernel command called igfx_off was introduced in commit
> ("Intel IOMMU: Intel IOMMU driver"). This command allows the user to
> disable the IOMMU dedicated to SOC-integrated graphic devices.
>
> Commit <9452618e7462>
> From: Lu Baolu
> Sent: Tuesday, January 30, 2024 2:08 PM
>
> Commit 62edf5dc4a524 ("intel-iommu: Restore DMAR_BROKEN_GFX_WA
> option for
> broken graphics drivers") was introduced 24 years ago as a temporary
> workaround for graphics drivers that used physical addresses for DMA and
> avoided
> From: Liu, Yi L
> Sent: Wednesday, June 14, 2023 2:14 PM
>
>
> > With that I think Jason's suggestion is to lift that test into main.c:
> >
> > int vfio_register_group_dev(struct vfio_device *device)
> > {
> > /*
> > * VFIO always sets IOMMU_CACHE because we offer no way for
>
> From: Liu, Yi L
> Sent: Wednesday, June 14, 2023 11:24 AM
>
> > From: Alex Williamson
> > Sent: Wednesday, June 14, 2023 4:11 AM
> >
> > On Tue, 13 Jun 2023 14:35:09 -0300
> > Jason Gunthorpe wrote:
> >
> > > On Tue, Jun 13, 2023 at 11:15:11AM -0600, Alex Williamson wrote:
> > > > [Sorry for
> From: Liu, Yi L
> Sent: Wednesday, May 24, 2023 10:21 AM
>
> > >
> > > vfio_device_open_file()
> > > {
> > > dev_warn(device->dev, "vfio-noiommu device opened by user "
> > > "(%s:%d)\n", current->comm, task_pid_nr(current));
> > > }
> >
> > There needs to be a taint when
> From: Liu, Yi L
> Sent: Thursday, May 18, 2023 9:26 PM
> > > +int vfio_iommufd_physical_devid(struct vfio_device *vdev)
> > > +{
> > > + if (vdev->iommufd_device)
> > > + return iommufd_device_to_id(vdev->iommufd_device);
> > > + if (vdev->noiommu_access)
> > > + return
> From: Liu, Yi L
> Sent: Friday, April 28, 2023 2:21 PM
>
> On 2023/4/28 02:32, Alex Williamson wrote:
> > On Thu, 27 Apr 2023 06:59:17 +
> > "Liu, Yi L" wrote:
> >
> >>> From: Tian, Kevin
> >>> Sent: Thursday, April 27, 2
> From: Liu, Yi L
> Sent: Wednesday, April 26, 2023 10:54 PM
>
> +static bool vfio_dev_in_iommufd_ctx(struct vfio_pci_core_device *vdev,
> + struct iommufd_ctx *iommufd_ctx)
> +{
> + struct iommufd_ctx *iommufd = vfio_iommufd_physical_ictx(
> >vdev);
> +
> From: Liu, Yi L
> Sent: Wednesday, April 26, 2023 10:54 PM
> +
> +/*
> + * Check if a given iommu_group has been bound to an iommufd within a
> + * devset. Returns true if there is device in the devset which is in
> + * the input iommu_group and meanwhile bound to the input iommufd.
> + *
> From: Yi Liu
> Sent: Wednesday, April 26, 2023 10:54 PM
> +
> +/*
> + * Return devid for devices that have been bound with iommufd,
> + * returns 0 if not bound yet.
> + */
> +u32 vfio_iommufd_physical_devid(struct vfio_device *vdev)
> +{
> + if (WARN_ON(!vdev->iommufd_device &&
> From: Liu, Yi L
> Sent: Wednesday, April 26, 2023 10:54 PM
>
> VFIO needs two reserved values. 0 is already reserved by initializing
> xarray with XA_FLAGS_ALLOC1. This reserves -1 by limiting the xa alloc
> range.
>
> Signed-off-by: Yi Liu
> ---
> drivers/iommu/iommufd/main.c | 5 -
>
> From: Liu, Yi L
> Sent: Wednesday, April 26, 2023 10:54 PM
>
> Use it to differentiate whether to report group_id or dev_id in revised
> VFIO_DEVICE_GET_PCI_HOT_RESET_INFO ioctl. Though it is not set at this
> moment introducing it now allows us to get hot reset ready for cdev.
>
>
> From: Liu, Yi L
> Sent: Wednesday, April 26, 2023 10:54 PM
>
> This prepares to add another method for hot reset. The major hot reset logic
> are moved to vfio_pci_ioctl_pci_hot_reset_groups().
>
> No functional change is intended.
>
> Suggested-by: Jason Gunthorpe
> Signed-off-by: Jason
> From: Liu, Yi L
> Sent: Wednesday, April 26, 2023 10:54 PM
> @@ -121,7 +128,8 @@ static void vfio_emulated_unmap(void *data,
> unsigned long iova,
> {
> struct vfio_device *vdev = data;
>
> - if (vdev->ops->dma_unmap)
> + /* noiommu devices cannot do map/unmap */
> + if
> From: Liu, Yi L
> Sent: Wednesday, April 26, 2023 10:54 PM
>
> -static inline bool vfio_device_is_noiommu(struct vfio_device *vdev)
> +static inline int vfio_device_set_noiommu(struct vfio_device *device)
> {
> - return IS_ENABLED(CONFIG_VFIO_NOIOMMU) &&
> -vdev->group->type
> From: Alex Williamson
> Sent: Tuesday, April 18, 2023 12:11 PM
>
> On Tue, 18 Apr 2023 03:24:46 +0000
> "Tian, Kevin" wrote:
>
> > > From: Alex Williamson
> > > Sent: Tuesday, April 18, 2023 4:07 AM
> > >
> > >
> From: Alex Williamson
> Sent: Tuesday, April 18, 2023 4:07 AM
>
> On Mon, 17 Apr 2023 16:31:56 -0300
> Jason Gunthorpe wrote:
>
> > On Mon, Apr 17, 2023 at 01:01:40PM -0600, Alex Williamson wrote:
> > > Yes, it's not trivial, but Jason is now proposing that we consider
> > > mixing groups,
> From: Jason Gunthorpe
> Sent: Monday, April 17, 2023 9:39 PM
>
> On Fri, Apr 14, 2023 at 09:11:30AM +, Tian, Kevin wrote:
>
> > The only corner case with this option is when a user mixes group
> > and cdev usages. iirc you mentioned it's a valid usage to be
> From: Alex Williamson
> Sent: Friday, April 14, 2023 2:07 AM
>
> We had already iterated a proposal where the group-id is replaced with
> a dev-id in the existing ioctl and a flag indicates when the return
> value is a dev-id vs group-id. This had a gap that userspace cannot
> determine if a
> From: Jason Gunthorpe
> 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
> From: Jason Gunthorpe
> Sent: Wednesday, April 12, 2023 11:06 PM
>
> On Wed, Apr 12, 2023 at 07:27:43AM +, Tian, Kevin wrote:
> > > From: Jason Gunthorpe
> > > Sent: Wednesday, April 12, 2023 8:01 AM
> > >
> > > I see this prob
> From: Jason Gunthorpe
> Sent: Wednesday, April 12, 2023 8:01 AM
>
> I see this problem as a few basic requirements from a qemu-like
> application:
>
> 1) Does the configuration I was given support reset right now?
> 2) Will the configuration I was given support reset for the duration
>
> From: Alex Williamson
> Sent: Wednesday, April 12, 2023 5:58 AM
>
> On Tue, 11 Apr 2023 15:40:07 -0300
> Jason Gunthorpe wrote:
>
> > On Tue, Apr 11, 2023 at 11:11:17AM -0600, Alex Williamson wrote:
> > > [Appears the list got dropped, replying to my previous message to re-add]
> >
> > Wowo
> From: Jason Gunthorpe
> Sent: Thursday, March 30, 2023 4:00 AM
>
> On Mon, Mar 27, 2023 at 02:33:47AM -0700, Yi Liu wrote:
> > @@ -494,6 +479,30 @@ void iommufd_access_destroy(struct
> iommufd_access *access)
> > }
> > EXPORT_SYMBOL_NS_GPL(iommufd_access_destroy, IOMMUFD);
> >
> > +int
> From: Tian, Kevin
> Sent: Thursday, March 30, 2023 9:10 AM
>
> > From: Jason Gunthorpe
> > Sent: Wednesday, March 29, 2023 11:50 PM
> >
> > On Wed, Mar 29, 2023 at 09:41:26AM +, Tian, Kevin wrote:
> >
> > > We could extend bind_iommufd to re
> From: Jason Gunthorpe
> Sent: Wednesday, March 29, 2023 11:58 PM
>
> On Wed, Mar 29, 2023 at 09:49:44AM -0600, Alex Williamson wrote:
>
> > > We could extend bind_iommufd to return the group id or introduce a
> > > new ioctl to query it per dev_id.
> >
> > That would be ironic to go to all
> From: Jason Gunthorpe
> Sent: Wednesday, March 29, 2023 11:50 PM
>
> On Wed, Mar 29, 2023 at 09:41:26AM +, Tian, Kevin wrote:
>
> > We could extend bind_iommufd to return the group id or introduce a
> > new ioctl to query it per dev_id.
>
> > Once
> From: Liu, Yi L
> Sent: Wednesday, March 29, 2023 11:14 AM
>
> > From: Alex Williamson
> > Sent: Wednesday, March 29, 2023 12:00 AM
> >
> >
> > Personally I don't like the suggestion to fail with -EPERM if the user
> > doesn't own all the affected devices. This isn't a "probe if I can do
> >
> From: Liu, Yi L
> Sent: Monday, March 27, 2023 5:41 PM
>
> For noiommu device, vfio core names the cdev node with prefix "noiommu-".
>
> Signed-off-by: Yi Liu
Reviewed-by: Kevin Tian
> From: Liu, Yi L
> Sent: Monday, March 27, 2023 5:41 PM
>
> This adds a noiommu flag in vfio_device, hence caller of the
> vfio_device_is_noiommu() just refers to the flag for noiommu
> check.
>
> Signed-off-by: Yi Liu
Reviewed-by: Kevin Tian
> From: Liu, Yi L
> Sent: Tuesday, March 28, 2023 11:32 AM
>
> > From: Alex Williamson
> > Sent: Tuesday, March 28, 2023 3:26 AM
> >
> > Additionally, VFIO_DEVICE_GET_PCI_HOT_RESET_INFO has a flags arg that
> > isn't used, why do we need a new ioctl vs defining
> >
> From: Liu, Yi L
> Sent: Monday, March 27, 2023 5:34 PM
>
> no need to pass the iommufd_ucmd pointer.
>
> Signed-off-by: Yi Liu
Reviewed-by: Kevin Tian
> From: Alex Williamson
> Sent: Wednesday, March 22, 2023 5:01 AM
>
> On Tue, 21 Mar 2023 17:50:08 -0300
> Jason Gunthorpe wrote:
>
> >
> > Though it would be nice if qemu didn't need two implementations so Yi
> > I'd rather see a new info in this series as well and qemu can just
> >
> From: Jason Gunthorpe
> Sent: Tuesday, March 21, 2023 1:17 AM
>
> On Mon, Mar 20, 2023 at 10:31:53PM +0800, Yi Liu wrote:
> > On 2023/3/20 22:09, Jason Gunthorpe wrote:
> > > On Wed, Mar 15, 2023 at 04:40:19AM +, Liu, Yi L wrote:
> > >
> > > > # if IS_ENABLED(CONFIG_VFIO_GROUP)
> > > >
> From: Liu, Yi L
> Sent: Friday, March 17, 2023 11:07 AM
>
> > From: Tian, Kevin
> > Sent: Friday, March 17, 2023 10:14 AM
> >
> > > From: Liu, Yi L
> > > Sent: Thursday, March 16, 2023 8:55 PM
> > >
> > > +
> From: Liu, Yi L
> Sent: Thursday, March 16, 2023 8:56 PM
>
> This gives notes for userspace applications on device cdev usage.
>
> Signed-off-by: Yi Liu
Reviewed-by: Kevin Tian
> From: Yi Liu
> Sent: Thursday, March 16, 2023 8:56 PM
>
> +
> +static int vfio_device_cdev_enable_noiommu(struct vfio_device *device)
> +{
> + if (!vfio_device_is_noiommu(device))
> + return -EINVAL;
> +
> + if (!capable(CAP_SYS_RAWIO))
> + return -EPERM;
> +
> +
> From: Liu, Yi L
> Sent: Thursday, March 16, 2023 8:55 PM
> +
> +void vfio_iommufd_emulated_detach_ioas(struct vfio_device *vdev)
> +{
> + lockdep_assert_held(>dev_set->lock);
> +
> + if (WARN_ON(!vdev->iommufd_access) || !vdev->iommufd_attached)
> + return;
> +
ditto the
> From: Liu, Yi L
> Sent: Thursday, March 16, 2023 8:55 PM
>
> +void vfio_iommufd_physical_detach_ioas(struct vfio_device *vdev)
> +{
> + lockdep_assert_held(>dev_set->lock);
> +
> + if (WARN_ON(!vdev->iommufd_device) || !vdev->iommufd_attached)
> + return;
> +
the 2nd check
> From: Liu, Yi L
> Sent: Thursday, March 16, 2023 8:55 PM
>
> From: Nicolin Chen
>
> Previously, the detach routine is only done by the destroy(). And it was
> called by vfio_iommufd_emulated_unbind() when the device runs close(), so
> all the mappings in iopt were cleaned in that setup, when
> From: Liu, Yi L
> Sent: Thursday, March 16, 2023 8:55 PM
>
> .bind_iommufd() will generate an ID to represent this bond, which is
> needed by userspace for further usage. Store devid in vfio_device_file
> to avoid passing the pointer in multiple places.
>
> Signed-off-by: Yi Liu
> From: Liu, Yi L
> Sent: Thursday, March 16, 2023 8:55 PM
>
> to align with the coming vfio device cdev support.
>
> Signed-off-by: Yi Liu
Reviewed-by: Kevin Tian
> From: Liu, Yi L
> Sent: Thursday, March 16, 2023 8:55 PM
>
> @@ -192,6 +192,15 @@ static int vfio_device_group_open(struct
> vfio_device_file *df)
> vfio_device_group_get_kvm_safe(device);
>
> df->iommufd = device->group->iommufd;
> + if (device->group->iommufd &&
> From: Liu, Yi L
> Sent: Thursday, March 16, 2023 8:55 PM
>
> vfio_device_first_open() requires the caller to provide either a valid
> iommufd (the group path in iommufd compat mode) or a valid container
> (the group path in legacy container mode). As preparation for noiommu
> support in device
> From: Liu, Yi L
> Sent: Thursday, March 16, 2023 8:55 PM
>
> This defines KVM_DEV_VFIO_FILE* and make alias with
> KVM_DEV_VFIO_GROUP*.
> Old userspace uses KVM_DEV_VFIO_GROUP* works as well.
>
> Reviewed-by: Jason Gunthorpe
> Tested-by: Terrence Xu
> Tested-by: Nicolin Chen
> Tested-by:
> From: Liu, Yi L
> Sent: Thursday, March 16, 2023 8:55 PM
>
> since no user of vfio_file_is_group() now.
>
> Signed-off-by: Yi Liu
Reviewed-by: Kevin Tian
> From: Liu, Yi L
> Sent: Thursday, March 16, 2023 8:42 PM
>
> Now user can also provide an array of device fds as a 3rd method to verify
> the reset ownership. It's not useful at this point when the device fds are
> acquired via group fds. But it's necessary when moving to device cdev which
>
> From: Liu, Yi L
> Sent: Thursday, March 16, 2023 8:42 PM
>
> This extends both vfio_file_is_valid() and vfio_file_has_dev() to accept
> device file from the vfio PCI hot reset.
>
> Signed-off-by: Yi Liu
Reviewed-by: Kevin Tian
> From: Liu, Yi L
> Sent: Thursday, March 16, 2023 8:42 PM
>
> This prepares vfio core to accept vfio device file from the vfio PCI
> hot reset path. vfio_file_is_group() is still kept for KVM usage.
>
> Signed-off-by: Yi Liu
Reviewed-by: Kevin Tian
> From: Liu, Yi L
> Sent: Thursday, March 16, 2023 8:42 PM
> @@ -2469,7 +2469,8 @@ static int vfio_pci_dev_set_hot_reset(struct
> vfio_device_set *dev_set,
>* cannot race being opened by another user simultaneously.
>*
>* Otherwise all opened
> From: Liu, Yi L
> Sent: Thursday, March 16, 2023 8:42 PM
>
> as an alternative method for ownership check when iommufd is used. In
> this case all opened devices in the affected dev_set are verified to
> be bound to a same valid iommufd value to allow reset. It's simpler
> and faster as user
> From: Liu, Yi L
> Sent: Thursday, March 16, 2023 8:15 PM
>
> After making the no-DMA drivers (samples/vfio-mdev) providing iommufd
> callbacks, __vfio_register_dev() should check the presence of the iommufd
> callbacks if CONFIG_IOMMUFD is enabled.
>
> Reviewed-by: Jason Gunthorpe
>
> From: Liu, Yi L
> Sent: Thursday, March 16, 2023 8:15 PM
>
> This harmonizes the no-DMA devices (the vfio-mdev sample drivers) with
> the emulated devices (gvt-g, vfio-ap etc.). It makes it easier to add
> BIND_IOMMUFD user interface which requires to return an iommufd ID to
> represent the
> From: Yi Liu
> Sent: Thursday, March 16, 2023 8:15 PM
>
> iommufd_ctx is stored in vfio_device for emulated devices per
> bind_iommufd.
> However, as iommufd_access is created in bind, no more need to stored it
> since iommufd_access implicitly stores it.
>
> Reviewed-by: Jason Gunthorpe
>
> From: Alex Williamson
> Sent: Friday, March 17, 2023 8:23 AM
>
> On Thu, 16 Mar 2023 23:29:21 +0000
> "Tian, Kevin" wrote:
>
> > > From: Alex Williamson
> > > Sent: Friday, March 17, 2023 2:46 AM
> > >
> > > On Wed, 15 Mar 2023
> From: Alex Williamson
> Sent: Friday, March 17, 2023 2:46 AM
>
> On Wed, 15 Mar 2023 23:31:23 +0000
> "Tian, Kevin" wrote:
>
> > > From: Alex Williamson
> > > Sent: Thursday, March 16, 2023 6:53 AM
> > > I'm afraid th
> From: Liu, Yi L
> Sent: Thursday, March 16, 2023 11:55 AM
>
> > From: Tian, Kevin
> > Sent: Thursday, March 16, 2023 7:31 AM
> >
> > > From: Alex Williamson
> > > Sent: Thursday, March 16, 2023 6:53 AM
> > >
> &
> From: Nicolin Chen
> Sent: Thursday, March 16, 2023 1:44 PM
>
> On Thu, Mar 16, 2023 at 05:38:41AM +, Tian, Kevin wrote:
> > External email: Use caution opening links or attachments
> >
> >
> > > From: Nicolin Chen
> > > Sent: Thurs
> From: Nicolin Chen
> Sent: Thursday, March 16, 2023 1:33 PM
>
> Hi Kevin,
>
> I've fixed the other two commits. Here is the one that I am
> not sure about:
>
> On Thu, Mar 16, 2023 at 02:53:50AM +, Tian, Kevin wrote:
>
> > > [2] This adds iom
> From: Nicolin Chen
> Sent: Wednesday, March 15, 2023 5:03 PM
>
> Hi,
>
> On Wed, Mar 15, 2023 at 06:50:53AM +, Tian, Kevin wrote:
>
> > > So, this preparatory series will add a pair of simple attach()
> > > and detach() APIs. Th
> From: Liu, Yi L
> Sent: Wednesday, March 15, 2023 4:53 PM
>
> > From: Tian, Kevin
> > Sent: Wednesday, March 15, 2023 2:52 PM
> >
> > > From: Nicolin Chen
> > > Sent: Wednesday, March 15, 2023 2:22 PM
> > >
> > > On Wed, Mar 15
> From: Alex Williamson
> Sent: Thursday, March 16, 2023 6:53 AM
>
> On Wed, 8 Mar 2023 05:28:51 -0800
> Yi Liu wrote:
>
> > This is another method to issue PCI hot reset for the users that bounds
> > device to a positive iommufd value. In such case, iommufd is a proof of
> > device
> From: Liu, Yi L
> Sent: Wednesday, March 15, 2023 12:40 PM
>
> > From: Tian, Kevin
> > Sent: Friday, March 10, 2023 6:07 PM
> >
> > > From: Liu, Yi L
> > > Sent: Friday, March 10, 2023 5:58 PM
> > >
> > > &g
> From: Nicolin Chen
> Sent: Wednesday, March 15, 2023 2:22 PM
>
> On Wed, Mar 15, 2023 at 06:16:37AM +, Tian, Kevin wrote:
> > External email: Use caution opening links or attachments
> >
> >
> > > From: Nicolin Chen
> > > Sent: Wednesday, M
> From: Nicolin Chen
> Sent: Wednesday, March 15, 2023 2:33 PM
>
> On Wed, Mar 15, 2023 at 06:15:23AM +, Tian, Kevin wrote:
> > External email: Use caution opening links or attachments
> >
> >
> > > From: Nicolin Chen
> > > Sent: Wednesday, M
> From: Nicolin Chen
> Sent: Wednesday, March 15, 2023 2:51 AM
>
> On Fri, Mar 10, 2023 at 02:08:15AM +, Tian, Kevin wrote:
> > External email: Use caution opening links or attachments
> >
> >
> > > From: Liu, Yi L
> > > Sent: Wednesday, Marc
> From: Nicolin Chen
> Sent: Wednesday, March 15, 2023 9:01 AM
>
> Hi Jason/Kevin,
>
> >
> > Perhaps we can have iommufd_access_attach/detach in this series
> > along with a vfio_iommufd_emulated_detach_ioas, and the locking
> > will come with another patch in replace series?
>
> I recall that
> From: Liu, Yi L
> Sent: Saturday, March 11, 2023 6:24 PM
> > > >
> > > > - ret = vdev->ops->bind_iommufd(vdev, ictx, _id);
> > > > - if (ret)
> > > > - return ret;
> > > > + /* The legacy path has no way to return the device id */
> > > > + return
> From: Jason Gunthorpe
> Sent: Friday, March 10, 2023 10:04 PM
>
> On Fri, Mar 10, 2023 at 02:15:32AM +, Tian, Kevin wrote:
> > > From: Liu, Yi L
> > > Sent: Wednesday, March 8, 2023 9:14 PM
> > >
> > > After making the no-DMA drivers (sample
> From: Liu, Yi L
> Sent: Friday, March 10, 2023 5:58 PM
>
> > From: Tian, Kevin
> > Sent: Friday, March 10, 2023 5:02 PM
> >
> > > From: Liu, Yi L
> > > Sent: Wednesday, March 8, 2023 9:29 PM
> > > +
> > > +stati
> From: Liu, Yi L
> Sent: Friday, March 10, 2023 4:22 PM
>
> >
> > > +int vfio_iommufd_attach_compat_ioas(struct vfio_device *vdev,
> > > + struct iommufd_ctx *ictx)
> > > +{
> > > + u32 ioas_id;
> > > + int ret;
> > > +
> > > + lockdep_assert_held(>dev_set->lock);
>
> From: Liu, Yi L
> Sent: Friday, March 10, 2023 2:04 PM
> > > + *
> > > + * In the last case all affected devices which are opened by this user
> > > + * must have been bound to a same iommufd_ctx. This approach is only
> > > + * available for devices bound to positive iommufd.
> >
> > As we
> From: Liu, Yi L
> Sent: Wednesday, March 8, 2023 9:29 PM
>
> group code is not needed for vfio device cdev, so with vfio device cdev
> introduced, the group infrastructures can be compiled out if only cdev
> is needed.
>
> Signed-off-by: Yi Liu
Reviewed-by: Kevin Tian
> From: Liu, Yi L
> Sent: Wednesday, March 8, 2023 9:29 PM
> +
> +static int vfio_device_cdev_probe_noiommu(struct vfio_device *device)
> +{
> + struct iommu_group *iommu_group;
> + int ret = 0;
> +
> + if (!IS_ENABLED(CONFIG_VFIO_NOIOMMU) || !vfio_noiommu)
> + return
> From: Liu, Yi L
> Sent: Wednesday, March 8, 2023 9:29 PM
>
> + /*
> + * Placing it before vfio_device_put_registration() to prevent
> + * new registration refcount increment by
> VFIO_GROUP_GET_DEVICE_FD
> + * during the unregister time.
> + */
> +
> From: Liu, Yi L
> Sent: Wednesday, March 8, 2023 9:29 PM
>
> bind_iommufd() will generate an ID to represent this bond, it is needed
> by userspace for further usage. devid is stored in vfio_device_file to
> avoid passing devid pointer in multiple places.
after removing vfio_iommufd_bind()
> From: Liu, Yi L
> Sent: Wednesday, March 8, 2023 9:29 PM
>
> +/*
> + * This shall be used without group lock as group and group->container
> + * should be fixed before group is set to df->group.
> + */
/* No group lock since df->group and df->group->container cannot change */
> +bool
> From: Liu, Yi L
> Sent: Wednesday, March 8, 2023 9:29 PM
>
> @@ -177,7 +177,7 @@ static int vfio_device_group_open(struct
> vfio_device_file *df)
> mutex_lock(>group->group_lock);
> if (!vfio_group_has_iommu(device->group)) {
> ret = -EINVAL;
> - goto
> From: Yi Liu
> Sent: Wednesday, March 8, 2023 9:29 PM
>
> This is another method to issue PCI hot reset for the users that bounds
> device to a positive iommufd value. In such case, iommufd is a proof of
> device ownership. By passing a zero-length fd array, user indicates kernel
> to do
> From: Liu, Yi L
> Sent: Wednesday, March 8, 2023 9:29 PM
>
> @@ -1319,8 +1319,14 @@ static int vfio_pci_ioctl_pci_hot_reset(struct
> vfio_pci_core_device *vdev,
> break;
> }
>
> - /* Ensure the FD is a vfio group FD.*/
> - if
> From: Liu, Yi L
> Sent: Wednesday, March 8, 2023 9:29 PM
>
> No function change is intended, just to make the helpers and structures
> to be prepared to accept device fds as proof of device ownership.
>
> Signed-off-by: Yi Liu
> ---
> drivers/vfio/pci/vfio_pci_core.c | 40
> From: Liu, Yi L
> Sent: Wednesday, March 8, 2023 9:29 PM
>
> @@ -2429,10 +2429,23 @@ static int vfio_pci_dev_set_hot_reset(struct
> vfio_device_set *dev_set,
>
> list_for_each_entry(cur_vma, _set->device_list,
> vdev.dev_set_list) {
> /*
> - * Test whether all
> From: Liu, Yi L
> Sent: Wednesday, March 8, 2023 9:29 PM
>
> @@ -1114,6 +1114,10 @@ static long vfio_device_fops_unl_ioctl(struct file
> *filep,
> struct vfio_device *device = df->device;
> int ret;
>
> + /* Paired with smp_store_release() in vfio_device_group_open() */
> +
> From: Liu, Yi L
> Sent: Wednesday, March 8, 2023 9:14 PM
>
> After making the no-DMA drivers (samples/vfio-mdev) providing iommufd
> callbacks, __vfio_register_dev() should check the presence of the iommufd
> callbacks if CONFIG_IOMMUFD is enabled.
>
> Signed-off-by: Yi Liu
> ---
>
> From: Liu, Yi L
> Sent: Wednesday, March 8, 2023 9:14 PM
>
> @@ -32,12 +32,8 @@ int vfio_iommufd_bind(struct vfio_device *vdev,
> struct iommufd_ctx *ictx)
> return 0;
> }
>
> - /*
> - * If the driver doesn't provide this op then it means the device does
> -
> From: Liu, Yi L
> Sent: Wednesday, March 8, 2023 9:14 PM
>
> vfio device cdev needs to return iommufd_access ID to userspace if
> bind_iommufd succeeds.
>
> Signed-off-by: Yi Liu
Reviewed-by: Kevin Tian
> From: Liu, Yi L
> Sent: Wednesday, March 8, 2023 9:14 PM
>
> @@ -449,33 +450,18 @@ iommufd_access_create(struct iommufd_ctx *ictx,
> u32 ioas_id,
> access->data = data;
> access->ops = ops;
>
> - obj = iommufd_get_object(ictx, ioas_id, IOMMUFD_OBJ_IOAS);
> - if
> From: Liu, Yi L
> Sent: Wednesday, March 8, 2023 4:01 PM
>
> > From: Tian, Kevin
> > Sent: Wednesday, March 8, 2023 3:55 PM
> >
> > > From: Liu, Yi L
> > > Sent: Wednesday, March 8, 2023 3:47 PM
> > >
> > > >
> From: Liu, Yi L
> Sent: Wednesday, March 8, 2023 3:47 PM
>
> > From: Tian, Kevin
> > Sent: Wednesday, March 8, 2023 3:26 PM
> >
> > > From: Liu, Yi L
> > > Sent: Tuesday, March 7, 2023 9:29 PM
> > >
> > > >
> >
> From: Liu, Yi L
> Sent: Tuesday, March 7, 2023 9:29 PM
>
> >
> > I really prefer the 'use the iommufd option' still exist, it is so
> > much cleaner and easier for the actual users of this API. We've lost
> > the point by worrying about no iommu.
>
> Hmmm, so you are suggesting to have both
> From: Liu, Yi L
> Sent: Tuesday, March 7, 2023 9:04 PM
>
> > From: Jason Gunthorpe
> > Sent: Tuesday, March 7, 2023 8:38 PM
> >
> > On Tue, Mar 07, 2023 at 06:38:59AM +, Tian, Kevin wrote:
> > > > From: Liu, Yi L
> > > > Sent: Fr
> From: Liu, Yi L
> Sent: Friday, March 3, 2023 2:58 PM
>
> > What should we return here anyhow if an access was created?
>
> iommufd_access->obj.id. should be fine. Is it?
>
Thinking more I'm not sure whether it's a good idea to fill the
dev_id field with an access object id and then later
> From: Jason Gunthorpe
> Sent: Monday, March 6, 2023 9:17 PM
>
> On Fri, Mar 03, 2023 at 09:55:42AM -0700, Alex Williamson wrote:
>
> > I can't think of a reason DPDK couldn't use hot-reset. If we want to
> > make it a policy, it should be enforced by code, but creating that
> > policy based
> From: Tian, Kevin
> Sent: Monday, March 6, 2023 4:17 PM
>
> > From: Liu, Yi L
> > Sent: Sunday, March 5, 2023 10:49 PM
> >
> >
> > How about falling back to prior solution. Allow userspace to pass a set
> > of device fd, and the kernel just chec
> From: Liu, Yi L
> Sent: Sunday, March 5, 2023 10:49 PM
>
> > From: Alex Williamson
> > Sent: Saturday, March 4, 2023 12:56 AM
> >
> > On Fri, 3 Mar 2023 06:36:35 +
> > "Tian, Kevin" wrote:
> >
> > > use of noiommu should be
> From: Liu, Yi L
> Sent: Thursday, March 2, 2023 10:20 PM
>
> > From: Jason Gunthorpe
> > Sent: Thursday, March 2, 2023 8:35 PM
> >
> > On Thu, Mar 02, 2023 at 09:55:46AM +, Tian, Kevin wrote:
> > > > From: Liu, Yi L
> From: Liu, Yi L
> Sent: Thursday, March 2, 2023 2:07 PM
>
> > - if (!vfio_dev_in_groups(cur_vma, groups)) {
> > + if (cur_vma->vdev.open_count &&
> > + !vfio_dev_in_groups(cur_vma, groups) &&
> > + !vfio_dev_in_iommufd_ctx(cur_vma, iommufd_ctx))
> From: Liu, Yi L
> Sent: Friday, February 24, 2023 11:44 AM
> > > Upon reflection we can probably make it even simpler and just have a 0
> > > length fd array mean to use the iommufd the vfio_device is already
> > > associated with
> > >
> > > And the check for correctness can be simplified to
> From: Jason Gunthorpe
> Sent: Friday, February 24, 2023 10:36 AM
>
> On Fri, Feb 24, 2023 at 02:21:33AM +, Tian, Kevin wrote:
>
> > Yi, while you are incorporating this change please also update the
> > uapi header. Rename 'group_fds[]' to 'fds[]' and
> From: Jason Gunthorpe
> Sent: Thursday, February 23, 2023 9:22 PM
>
> On Thu, Feb 23, 2023 at 07:55:21AM +, Tian, Kevin wrote:
> > > From: Jason Gunthorpe
> > > Sent: Thursday, February 23, 2023 1:18 AM
> > >
> > > > > static boo
1 - 100 of 284 matches
Mail list logo
