Re: [PATCH v12 07/24] vfio: Block device access via device fd until device is opened

Alex Williamson
2023-06-12T21:53:28Z

On Fri, 2 Jun 2023 05:16:36 -0700
Yi Liu <yi.l.liu@intel.com> wrote:

> Allow the vfio_device file to be in a state where the device FD is
> opened but the device cannot be used by userspace (i.e. its .open_device()
> hasn't been called). This inbetween state is not used when the device
> FD is spawned from the group FD, however when we create the device FD
> directly by opening a cdev it will be opened in the blocked state.
>
> The reason for the inbetween state is that userspace only gets a FD but
> doesn't gain access permission until binding the FD to an iommufd. So in
> the blocked state, only the bind operation is allowed. Completing bind
> will allow user to further access the device.
>
> This is implemented by adding a flag in struct vfio_device_file to mark
> the blocked state and using a simple smp_load_acquire() to obtain the
> flag value and serialize all the device setup with the thread accessing
> this device.
>
> Following this lockless scheme, it can safely handle the device FD
> unbound->bound but it cannot handle bound->unbound. To allow this we'd
> need to add a lock on all the vfio ioctls which seems costly. So once
> device FD is bound, it remains bound until the FD is closed.
>
> Suggested-by: Jason Gunthorpe <jgg@nvidia.com>
> Reviewed-by: Kevin Tian <kevin.tian@intel.com>
> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
> Reviewed-by: Eric Auger <eric.auger@redhat.com>
> Tested-by: Terrence Xu <terrence.xu@intel.com>
> Tested-by: Nicolin Chen <nicolinc@nvidia.com>
> Tested-by: Matthew Rosato <mjrosato@linux.ibm.com>
> Tested-by: Yanting Jiang <yanting.jiang@intel.com>
> Tested-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
> Signed-off-by: Yi Liu <yi.l.liu@intel.com>
> ---
> drivers/vfio/group.c | 11 ++++++++++-
> drivers/vfio/vfio.h | 1 +
> drivers/vfio/vfio_main.c | 16 ++++++++++++++++
> 3 files changed, 27 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/vfio/group.c b/drivers/vfio/group.c
> index caf53716ddb2..088dd34c8931 100644
> --- a/drivers/vfio/group.c
> +++ b/drivers/vfio/group.c
> @@ -194,9 +194,18 @@ static int vfio_df_group_open(struct vfio_device_file *df)
> df->iommufd = device->group->iommufd;
>
> ret = vfio_df_open(df);
> - if (ret)
> + if (ret) {
> df->iommufd = NULL;
> + goto out_put_kvm;
> + }
> +
> + /*
> + * Paired with smp_load_acquire() in vfio_device_fops::ioctl/
> + * read/write/mmap and vfio_file_has_device_access()
> + */
> + smp_store_release(&df->access_granted, true);
>
> +out_put_kvm:
> if (device->open_count == 0)
> vfio_device_put_kvm(device);
>
> diff --git a/drivers/vfio/vfio.h b/drivers/vfio/vfio.h
> index f9eb52eb9ed7..fdf2fc73f880 100644
> --- a/drivers/vfio/vfio.h
> +++ b/drivers/vfio/vfio.h
> @@ -18,6 +18,7 @@ struct vfio_container;
>
> struct vfio_device_file {
> struct vfio_device *device;
> + bool access_granted;

Should we make this a more strongly defined data type and later move
devid (u32) here to partially fill the hole created?

I think this is being placed towards the front of the data structure
for cache line locality given this is a hot path for file operations.
But bool types have an implementation dependent size, making them
difficult to pack. Also there will be a tendency to want to make this
a bit field, which is probably not compatible with the smp lockless
operations being used here. We might get in front of these issues if
we just define it as a u8 now. Thanks,

Alex

> spinlock_t kvm_ref_lock; /* protect kvm field */
> struct kvm *kvm;
> struct iommufd_ctx *iommufd; /* protected by struct vfio_device_set::lock */
> diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
> index a3c5817fc545..4c8b7713dc3d 100644
> --- a/drivers/vfio/vfio_main.c
> +++ b/drivers/vfio/vfio_main.c
> @@ -1129,6 +1129,10 @@ static long vfio_device_fops_unl_ioctl(struct file *filep,
> struct vfio_device *device = df->device;
> int ret;
>
> + /* Paired with smp_store_release() following vfio_df_open() */
> + if (!smp_load_acquire(&df->access_granted))
> + return -EINVAL;
> +
> ret = vfio_device_pm_runtime_get(device);
> if (ret)
> return ret;
> @@ -1156,6 +1160,10 @@ static ssize_t vfio_device_fops_read(struct file *filep, char __user *buf,
> struct vfio_device_file *df = filep->private_data;
> struct vfio_device *device = df->device;
>
> + /* Paired with smp_store_release() following vfio_df_open() */
> + if (!smp_load_acquire(&df->access_granted))
> + return -EINVAL;
> +
> if (unlikely(!device->ops->read))
> return -EINVAL;
>
> @@ -1169,6 +1177,10 @@ static ssize_t vfio_device_fops_write(struct file *filep,
> struct vfio_device_file *df = filep->private_data;
> struct vfio_device *device = df->device;
>
> + /* Paired with smp_store_release() following vfio_df_open() */
> + if (!smp_load_acquire(&df->access_granted))
> + return -EINVAL;
> +
> if (unlikely(!device->ops->write))
> return -EINVAL;
>
> @@ -1180,6 +1192,10 @@ static int vfio_device_fops_mmap(struct file *filep, struct vm_area_struct *vma)
> struct vfio_device_file *df = filep->private_data;
> struct vfio_device *device = df->device;
>
> + /* Paired with smp_store_release() following vfio_df_open() */
> + if (!smp_load_acquire(&df->access_granted))
> + return -EINVAL;
> +
> if (unlikely(!device->ops->mmap))
> return -EINVAL;
>