[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210921160108.GO327412@nvidia.com>
Date: Tue, 21 Sep 2021 13:01:08 -0300
From: Jason Gunthorpe <jgg@...dia.com>
To: Liu Yi L <yi.l.liu@...el.com>
Cc: alex.williamson@...hat.com, hch@....de, jasowang@...hat.com,
joro@...tes.org, jean-philippe@...aro.org, kevin.tian@...el.com,
parav@...lanox.com, lkml@...ux.net, pbonzini@...hat.com,
lushenming@...wei.com, eric.auger@...hat.com, corbet@....net,
ashok.raj@...el.com, yi.l.liu@...ux.intel.com,
jun.j.tian@...el.com, hao.wu@...el.com, dave.jiang@...el.com,
jacob.jun.pan@...ux.intel.com, kwankhede@...dia.com,
robin.murphy@....com, kvm@...r.kernel.org,
iommu@...ts.linux-foundation.org, dwmw2@...radead.org,
linux-kernel@...r.kernel.org, baolu.lu@...ux.intel.com,
david@...son.dropbear.id.au, nicolinc@...dia.com
Subject: Re: [RFC 03/20] vfio: Add vfio_[un]register_device()
On Sun, Sep 19, 2021 at 02:38:31PM +0800, Liu Yi L wrote:
> With /dev/vfio/devices introduced, now a vfio device driver has three
> options to expose its device to userspace:
>
> a) only legacy group interface, for devices which haven't been moved to
> iommufd (e.g. platform devices, sw mdev, etc.);
>
> b) both legacy group interface and new device-centric interface, for
> devices which supports iommufd but also wants to keep backward
> compatibility (e.g. pci devices in this RFC);
>
> c) only new device-centric interface, for new devices which don't carry
> backward compatibility burden (e.g. hw mdev/subdev with pasid);
We shouldn't have 'b'? Where does it come from?
> This patch introduces vfio_[un]register_device() helpers for the device
> drivers to specify the device exposure policy to vfio core. Hence the
> existing vfio_[un]register_group_dev() become the wrapper of the new
> helper functions. The new device-centric interface is described as
> 'nongroup' to differentiate from existing 'group' stuff.
Detect what the driver supports based on the ops it declares. There
should be a function provided through the ops for the driver to bind
to the iommufd.
> One open about how to organize the device nodes under /dev/vfio/devices/.
> This RFC adopts a simple policy by keeping a flat layout with mixed devname
> from all kinds of devices. The prerequisite of this model is that devnames
> from different bus types are unique formats:
This isn't reliable, the devname should just be vfio0, vfio1, etc
The userspace can learn the correct major/minor by inspecting the
sysfs.
This whole concept should disappear into the prior patch that adds the
struct device in the first place, and I think most of the code here
can be deleted once the struct device is used properly.
Jason
Powered by blists - more mailing lists