On Fri,  2 Jun 2023 05:16:36 -0700
Yi Liu <[email protected]> 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 <[email protected]>
> Reviewed-by: Kevin Tian <[email protected]>
> Reviewed-by: Jason Gunthorpe <[email protected]>
> Reviewed-by: Eric Auger <[email protected]>
> Tested-by: Terrence Xu <[email protected]>
> Tested-by: Nicolin Chen <[email protected]>
> Tested-by: Matthew Rosato <[email protected]>
> Tested-by: Yanting Jiang <[email protected]>
> Tested-by: Shameer Kolothum <[email protected]>
> Signed-off-by: Yi Liu <[email protected]>
> ---
>  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;
>  

Reply via email to