Allow mdev drivers to directly create the vfio_device (v3)

[Jason Gunthorpe]

On Tue, Jun 15, 2021 at 01:35:49PM -0600, Alex Williamson wrote:
> On Tue, 15 Jun 2021 15:35:09 +0200
> Christoph Hellwig <hch at lst.de> wrote:
> 
> > This is my alternative take on this series from Jason:
> > 
> > https://lore.kernel.org/dri-devel/87czsszi9i.fsf@redhat.com/T/
> > 
> > The mdev/vfio parts are exactly the same, but this solves the driver core
> > changes for the direct probing without the in/out flag that Greg hated,
> > which cause a little more work, but probably make the result better.
> > 
> > Original decription from Jason below:
> > 
> > The mdev bus's core part for managing the lifecycle of devices is mostly
> > as one would expect for a driver core bus subsystem.
> > 
> > However instead of having a normal 'struct device_driver' and binding the
> > actual mdev drivers through the standard driver core mechanisms it open
> > codes this with the struct mdev_parent_ops and provides a single driver
> > that shims between the VFIO core's struct vfio_device and the actual
> > device driver.
> > 
> > Instead, allow mdev drivers implement an actual struct mdev_driver and
> > directly call vfio_register_group_dev() in the probe() function for the
> > mdev. Arrange to bind the created mdev_device to the mdev_driver that is
> > provided by the end driver.
> > 
> > The actual execution flow doesn't change much, eg what was
> > parent_ops->create is now device_driver->probe and it is called at almost
> > the exact same time - except under the normal control of the driver core.
> > 
> > Ultimately converting all the drivers unlocks a fair number of additional
> > VFIO simplifications and cleanups.
> 
> Looks like we need an update to
> Documentation/driver-api/vfio-mediated-device.rst to go along with
> this.

I have those updates in the patch that removes the old way, do you
want to move them forward to here?

> Also, if we're preserving compatibility with the "legacy"
> mdev_parent_ops callbacks without deprecating them,

I view this as breaking up the work into manageable steps and patch
series. This is already at 10 patches just to provide the
infrastructure. The next steps will be to move the driver conversions
ahead.

> does it really make sense to convert every one of the sample drivers
> to this new direct registration?  

Yes, the rest of the drivers will get converted eventually too. There
is no reason to hold things back. Depending on timelines we might be
able to get AP into this cycle too...

Jason