From: Alex Williamson <alex.williamson@redhat.com>
To: Christoph Hellwig <hch@lst.de>
Cc: kvm@vger.kernel.org, linux-doc@vger.kernel.org,
David Airlie <airlied@linux.ie>,
dri-devel@lists.freedesktop.org,
Kirti Wankhede <kwankhede@nvidia.com>,
linux-s390@vger.kernel.org, Jonathan Corbet <corbet@lwn.net>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Halil Pasic <pasic@linux.ibm.com>,
Christian Borntraeger <borntraeger@de.ibm.com>,
Jason Gunthorpe <jgg@nvidia.com>,
intel-gfx@lists.freedesktop.org,
Jason Herne <jjherne@linux.ibm.com>,
Vasily Gorbik <gor@linux.ibm.com>,
Heiko Carstens <hca@linux.ibm.com>,
Rodrigo Vivi <rodrigo.vivi@intel.com>,
Tony Krowiak <akrowiak@linux.ibm.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Cornelia Huck <cohuck@redhat.com>
Subject: Re: Allow mdev drivers to directly create the vfio_device (v3)
Date: Tue, 15 Jun 2021 13:35:49 -0600 [thread overview]
Message-ID: <20210615133549.362e5a9e.alex.williamson@redhat.com> (raw)
In-Reply-To: <20210615133519.754763-1-hch@lst.de>
On Tue, 15 Jun 2021 15:35:09 +0200
Christoph Hellwig <hch@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.
Also, if we're preserving compatibility with the "legacy"
mdev_parent_ops callbacks without deprecating them, does it really make
sense to convert every one of the sample drivers to this new direct
registration? Thanks,
Alex
next prev parent reply other threads:[~2021-06-15 19:35 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20210615133519.754763-1-hch@lst.de>
[not found] ` <20210615133519.754763-5-hch@lst.de>
2021-06-15 14:03 ` [PATCH 04/10] driver core: Don't return EPROBE_DEFER to userspace during sysfs bind Cornelia Huck
2021-06-15 19:36 ` Alex Williamson
[not found] ` <20210615133519.754763-8-hch@lst.de>
2021-06-15 14:06 ` [PATCH 07/10] vfio/mdev: Allow the mdev_parent_ops to specify the device driver to bind Cornelia Huck
2021-06-15 14:11 ` Greg Kroah-Hartman
2021-06-16 0:00 ` Jason Gunthorpe
2021-06-16 6:39 ` Greg Kroah-Hartman
2021-06-16 20:20 ` Kirti Wankhede
[not found] ` <20210615133519.754763-6-hch@lst.de>
2021-06-15 14:10 ` [PATCH 05/10] driver core: Export device_driver_attach() Greg Kroah-Hartman
[not found] ` <20210615133519.754763-10-hch@lst.de>
2021-06-15 14:12 ` [PATCH 09/10] vfio/mdpy: Convert to use vfio_register_group_dev() Greg Kroah-Hartman
[not found] ` <20210615133519.754763-11-hch@lst.de>
2021-06-15 14:12 ` [PATCH 10/10] vfio/mbochs: " Greg Kroah-Hartman
2021-06-15 19:35 ` Alex Williamson [this message]
2021-06-15 20:35 ` Allow mdev drivers to directly create the vfio_device (v3) Jason Gunthorpe
[not found] ` <20210616031313.GA24992@lst.de>
2021-06-16 14:03 ` Jason Gunthorpe
[not found] ` <20210615133519.754763-3-hch@lst.de>
2021-06-15 13:53 ` [PATCH 02/10] driver core: Better distinguish probe errors in really_probe Cornelia Huck
2021-06-15 14:09 ` Greg Kroah-Hartman
2021-06-15 14:09 ` Greg Kroah-Hartman
2021-06-16 20:20 ` Kirti Wankhede
[not found] ` <20210615133519.754763-7-hch@lst.de>
2021-06-15 14:10 ` [PATCH 06/10] vfio/mdev: Remove CONFIG_VFIO_MDEV_DEVICE Greg Kroah-Hartman
2021-06-16 20:20 ` Kirti Wankhede
[not found] ` <20210615133519.754763-9-hch@lst.de>
2021-06-15 14:11 ` [PATCH 08/10] vfio/mtty: Convert to use vfio_register_group_dev() Greg Kroah-Hartman
2021-06-16 20:20 ` Kirti Wankhede
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210615133549.362e5a9e.alex.williamson@redhat.com \
--to=alex.williamson@redhat.com \
--cc=airlied@linux.ie \
--cc=akrowiak@linux.ibm.com \
--cc=borntraeger@de.ibm.com \
--cc=cohuck@redhat.com \
--cc=corbet@lwn.net \
--cc=dri-devel@lists.freedesktop.org \
--cc=gor@linux.ibm.com \
--cc=gregkh@linuxfoundation.org \
--cc=hca@linux.ibm.com \
--cc=hch@lst.de \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jgg@nvidia.com \
--cc=jjherne@linux.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=kwankhede@nvidia.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=pasic@linux.ibm.com \
--cc=rafael@kernel.org \
--cc=rodrigo.vivi@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).