linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alex Williamson <alex.williamson@redhat.com>
To: Cornelia Huck <cohuck@redhat.com>
Cc: Jason Wang <jasowang@redhat.com>,
	kvm@vger.kernel.org, linux-s390@vger.kernel.org,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	intel-gfx@lists.freedesktop.org,
	intel-gvt-dev@lists.freedesktop.org, kwankhede@nvidia.com,
	mst@redhat.com, tiwei.bie@intel.com,
	virtualization@lists.linux-foundation.org,
	netdev@vger.kernel.org, maxime.coquelin@redhat.com,
	cunming.liang@intel.com, zhihong.wang@intel.com,
	rob.miller@broadcom.com, xiao.w.wang@intel.com,
	haotian.wang@sifive.com, zhenyuw@linux.intel.com,
	zhi.a.wang@intel.com, jani.nikula@linux.intel.com,
	joonas.lahtinen@linux.intel.com, rodrigo.vivi@intel.com,
	airlied@linux.ie, daniel@ffwll.ch, farman@linux.ibm.com,
	pasic@linux.ibm.com, sebott@linux.ibm.com, oberpar@linux.ibm.com,
	heiko.carstens@de.ibm.com, gor@linux.ibm.com,
	borntraeger@de.ibm.com, akrowiak@linux.ibm.com,
	freude@linux.ibm.com, lingshan.zhu@intel.com, idos@mellanox.com,
	eperezma@redhat.com, lulu@redhat.com, parav@mellanox.com,
	christophe.de.dinechin@gmail.com, kevin.tian@intel.com,
	stefanha@redhat.com
Subject: Re: [PATCH V8 3/6] mdev: introduce device specific ops
Date: Tue, 5 Nov 2019 10:44:18 -0700	[thread overview]
Message-ID: <20191105104418.1735d800@x1.home> (raw)
In-Reply-To: <20191105175025.1a620844.cohuck@redhat.com>

On Tue, 5 Nov 2019 17:50:25 +0100
Cornelia Huck <cohuck@redhat.com> wrote:

> On Tue,  5 Nov 2019 17:32:37 +0800
> Jason Wang <jasowang@redhat.com> wrote:
> 
> > Currently, except for the create and remove, the rest of
> > mdev_parent_ops is designed for vfio-mdev driver only and may not help
> > for kernel mdev driver. With the help of class id, this patch
> > introduces device specific callbacks inside mdev_device
> > structure. This allows different set of callback to be used by
> > vfio-mdev and virtio-mdev.
> > 
> > Reviewed-by: Parav Pandit <parav@mellanox.com>
> > Signed-off-by: Jason Wang <jasowang@redhat.com>
> > ---
> >  .../driver-api/vfio-mediated-device.rst       | 35 +++++++++----
> >  MAINTAINERS                                   |  1 +
> >  drivers/gpu/drm/i915/gvt/kvmgt.c              | 18 ++++---
> >  drivers/s390/cio/vfio_ccw_ops.c               | 18 ++++---
> >  drivers/s390/crypto/vfio_ap_ops.c             | 14 +++--
> >  drivers/vfio/mdev/mdev_core.c                 | 24 ++++++++-
> >  drivers/vfio/mdev/mdev_private.h              |  5 ++
> >  drivers/vfio/mdev/vfio_mdev.c                 | 37 ++++++-------
> >  include/linux/mdev.h                          | 43 ++++-----------
> >  include/linux/mdev_vfio_ops.h                 | 52 +++++++++++++++++++
> >  samples/vfio-mdev/mbochs.c                    | 20 ++++---
> >  samples/vfio-mdev/mdpy.c                      | 20 ++++---
> >  samples/vfio-mdev/mtty.c                      | 18 ++++---
> >  13 files changed, 206 insertions(+), 99 deletions(-)
> >  create mode 100644 include/linux/mdev_vfio_ops.h
> >   
> 
> (...)
> 
> > @@ -172,10 +163,34 @@ that a driver should use to unregister itself with the mdev core driver::
> >  
> >  	extern void mdev_unregister_device(struct device *dev);
> >  
> > -It is also required to specify the class_id in create() callback through::
> > +As multiple types of mediated devices may be supported, class id needs
> > +to be specified in the create callback(). This could be done  
> 
> The brackets should probably go behind 'create'?
> 
> > +explicitly for the device that does not use on mdev bus for its  
> 
> "for devices that do not use the mdev bus" ?
> 
> But why wouldn't they? I feel like I've missed some discussion here :/

The device ops provide a route through mdev-core for known callbacks,
which is primarily useful when we have 1:N relation between mdev bus
driver and vendor drivers.  The obvious example here is vfio-mdev,
where we have GVT-g, vfio-ap, vfio-ccw, NVIDIA GRID, and various sample
drivers all advertising vfio-mdev support via their class id.  However,
if we have a tightly coupled vendor driver and mdev bus driver, as the
mlx5 support that Parav is developing, the claim is that they prefer
not to expose any device ops and intend to interact directly with the
mdev device.  At least that's my understanding.  Thanks,

Alex

> > +operation through:
> >  
> >  	int mdev_set_class(struct mdev_device *mdev, u16 id);
> >  
> > +For the device that uses on the mdev bus for its operation, the class  
> 
> "For devices that use the mdev bus..."
> 
> But same comment as above.
> 
> > +should provide helper function to set class id and device specific
> > +ops. E.g for vfio-mdev devices, the function to be called is::
> > +
> > +	int mdev_set_vfio_ops(struct mdev_device *mdev,
> > +                              const struct mdev_vfio_device_ops *vfio_ops);
> > +
> > +The class id (set by this function to MDEV_CLASS_ID_VFIO) is used to
> > +match a device with an mdev driver via its id table. The device
> > +specific callbacks (specified in *vfio_ops) are obtainable via
> > +mdev_get_vfio_ops() (for use by the mdev bus driver). A vfio-mdev
> > +device (class id MDEV_CLASS_ID_VFIO) uses the following
> > +device-specific ops:
> > +
> > +* open: open callback of vfio mediated device
> > +* close: close callback of vfio mediated device
> > +* ioctl: ioctl callback of vfio mediated device
> > +* read : read emulation callback
> > +* write: write emulation callback
> > +* mmap: mmap emulation callback
> > +
> >  Mediated Device Management Interface Through sysfs
> >  ==================================================  
> 
> Otherwise, looks good.


  reply	other threads:[~2019-11-05 17:44 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-05  9:32 [PATCH V8 0/6] mdev based hardware virtio offloading support Jason Wang
2019-11-05  9:32 ` [PATCH V8 1/6] mdev: class id support Jason Wang
2019-11-05 16:03   ` Cornelia Huck
2019-11-05  9:32 ` [PATCH V8 2/6] modpost: add support for mdev class id Jason Wang
2019-11-05 16:06   ` Cornelia Huck
2019-11-05  9:32 ` [PATCH V8 3/6] mdev: introduce device specific ops Jason Wang
2019-11-05 16:50   ` Cornelia Huck
2019-11-05 17:44     ` Alex Williamson [this message]
2019-11-05 18:28       ` Cornelia Huck
2019-11-06  3:48         ` Jason Wang
2019-11-05  9:32 ` [PATCH V8 4/6] mdev: introduce virtio device and its device ops Jason Wang
2019-11-05 16:57   ` Cornelia Huck
2019-11-05 17:47   ` Alex Williamson
2019-11-06  3:51     ` Jason Wang
2019-11-05  9:32 ` [PATCH V8 5/6] virtio: introduce a mdev based transport Jason Wang
2019-11-05 18:33   ` Cornelia Huck
2019-11-05  9:32 ` [PATCH V8 6/6] docs: sample driver to demonstrate how to implement virtio-mdev framework Jason Wang
2019-11-05 18:35   ` Cornelia Huck
2019-11-05 17:58 ` [PATCH V8 0/6] mdev based hardware virtio offloading support Alex Williamson
2019-11-06  3:56   ` Jason Wang
2019-11-06 19:03     ` Alex Williamson
2019-11-06 19:25       ` Michael S. Tsirkin
2019-11-06 21:13         ` Alex Williamson
2019-11-07  4:11           ` Jason Wang

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=20191105104418.1735d800@x1.home \
    --to=alex.williamson@redhat.com \
    --cc=airlied@linux.ie \
    --cc=akrowiak@linux.ibm.com \
    --cc=borntraeger@de.ibm.com \
    --cc=christophe.de.dinechin@gmail.com \
    --cc=cohuck@redhat.com \
    --cc=cunming.liang@intel.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=eperezma@redhat.com \
    --cc=farman@linux.ibm.com \
    --cc=freude@linux.ibm.com \
    --cc=gor@linux.ibm.com \
    --cc=haotian.wang@sifive.com \
    --cc=heiko.carstens@de.ibm.com \
    --cc=idos@mellanox.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-gvt-dev@lists.freedesktop.org \
    --cc=jani.nikula@linux.intel.com \
    --cc=jasowang@redhat.com \
    --cc=joonas.lahtinen@linux.intel.com \
    --cc=kevin.tian@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=kwankhede@nvidia.com \
    --cc=lingshan.zhu@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=lulu@redhat.com \
    --cc=maxime.coquelin@redhat.com \
    --cc=mst@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=oberpar@linux.ibm.com \
    --cc=parav@mellanox.com \
    --cc=pasic@linux.ibm.com \
    --cc=rob.miller@broadcom.com \
    --cc=rodrigo.vivi@intel.com \
    --cc=sebott@linux.ibm.com \
    --cc=stefanha@redhat.com \
    --cc=tiwei.bie@intel.com \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=xiao.w.wang@intel.com \
    --cc=zhenyuw@linux.intel.com \
    --cc=zhi.a.wang@intel.com \
    --cc=zhihong.wang@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).