Hi Eric,
> From: Eric Auger <eric.auger@xxxxxxxxxx>
> Sent: Thursday, January 19, 2023 12:11 AM
>
> Hi Yi,
>
> On 1/17/23 14:49, Yi Liu wrote:
> > This makes the vfio file kAPIs to accepte vfio device files, also a
> > preparation for vfio device cdev support.
> >
> > Signed-off-by: Yi Liu <yi.l.liu@xxxxxxxxx>
> > ---
> > drivers/vfio/vfio.h | 1 +
> > drivers/vfio/vfio_main.c | 51
> ++++++++++++++++++++++++++++++++++++----
> > 2 files changed, 48 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/vfio/vfio.h b/drivers/vfio/vfio.h
> > index ef5de2872983..53af6e3ea214 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;
> > + struct kvm *kvm;
> > };
> >
> > void vfio_device_put_registration(struct vfio_device *device);
> > diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
> > index 1aedfbd15ca0..dc08d5dd62cc 100644
> > --- a/drivers/vfio/vfio_main.c
> > +++ b/drivers/vfio/vfio_main.c
> > @@ -1119,13 +1119,23 @@ const struct file_operations vfio_device_fops
> = {
> > .mmap = vfio_device_fops_mmap,
> > };
> >
> > +static struct vfio_device *vfio_device_from_file(struct file *file)
> > +{
> > + struct vfio_device_file *df = file->private_data;
> > +
> > + if (file->f_op != &vfio_device_fops)
> > + return NULL;
> > + return df->device;
> > +}
> > +
> > /**
> > * vfio_file_is_valid - True if the file is usable with VFIO aPIS
> > * @file: VFIO group file or VFIO device file
> > */
> > bool vfio_file_is_valid(struct file *file)
> > {
> > - return vfio_group_from_file(file);
> > + return vfio_group_from_file(file) ||
> > + vfio_device_from_file(file);
> > }
> > EXPORT_SYMBOL_GPL(vfio_file_is_valid);
> >
> > @@ -1140,15 +1150,37 @@ EXPORT_SYMBOL_GPL(vfio_file_is_valid);
> > */
> > bool vfio_file_enforced_coherent(struct file *file)
> > {
> > - struct vfio_group *group = vfio_group_from_file(file);
> > + struct vfio_group *group;
> > + struct vfio_device *device;
> >
> > + group = vfio_group_from_file(file);
> > if (group)
> > return vfio_group_enforced_coherent(group);
> >
> > + device = vfio_device_from_file(file);
> > + if (device)
> > + return device_iommu_capable(device->dev,
> > +
> IOMMU_CAP_ENFORCE_CACHE_COHERENCY);
> > +
> > return true;
> > }
> > EXPORT_SYMBOL_GPL(vfio_file_enforced_coherent);
> >
> > +static void vfio_device_file_set_kvm(struct file *file, struct kvm *kvm)
> > +{
> > + struct vfio_device_file *df = file->private_data;
> > + struct vfio_device *device = df->device;
> > +
> > + /*
> > + * The kvm is first recorded in the df, and will be propagated
> > + * to vfio_device::kvm when the file binds iommufd successfully in
> > + * the vfio device cdev path.
> > + */
> > + mutex_lock(&device->dev_set->lock);
> it is not totally obvious to me why the
>
> device->dev_set->lock needs to be held here and why that lock in particular.
> Isn't supposed to protect the vfio_device_set. The header just mentions
> "the VFIO core will provide a lock that is held around
> open_device()/close_device() for all devices in the set."
The reason is the df->kvm was referenced in vfio_device_first_open() in
the below commit. To avoid race, a common lock is needed between the
set_kvm thread and the open thread. For group path, group_lock is used.
However, for cdev path, there may be no group_lock compiled, so need
to use another one. And dev_set->lock happens to be used in the open
path, so use it avoids to adding another specific lock.
https://lore.kernel.org/kvm/20230117134942.101112-8-yi.l.liu@xxxxxxxxx/
> > + df->kvm = kvm;
> > + mutex_unlock(&device->dev_set->lock);
Regards,
Yi Liu
