All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cornelia Huck <cohuck@redhat.com>
To: Jason Wang <jasowang@redhat.com>
Cc: stefanha@redhat.com, christophe.de.dinechin@gmail.com,
	kvm@vger.kernel.org, mst@redhat.com, airlied@linux.ie,
	joonas.lahtinen@linux.intel.com, heiko.carstens@de.ibm.com,
	dri-devel@lists.freedesktop.org,
	virtualization@lists.linux-foundation.org, kwankhede@nvidia.com,
	rob.miller@broadcom.com, linux-s390@vger.kernel.org,
	sebott@linux.ibm.com, lulu@redhat.com, eperezma@redhat.com,
	pasic@linux.ibm.com, borntraeger@de.ibm.com,
	haotian.wang@sifive.com, zhi.a.wang@intel.com,
	farman@linux.ibm.com, idos@mellanox.com, gor@linux.ibm.com,
	intel-gfx@lists.freedesktop.org, jani.nikula@linux.intel.com,
	xiao.w.wang@intel.com, freude@linux.ibm.com,
	zhenyuw@linux.intel.com, parav@mellanox.com,
	zhihong.wang@intel.com, rodrigo.vivi@intel.com,
	intel-gvt-dev@lists.freedesktop.org, akrowiak@linux.ibm.com,
	oberpar@linux.ibm.com, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, maxime.co
Subject: Re: [PATCH V4 3/6] mdev: introduce device specific ops
Date: Thu, 17 Oct 2019 17:07:55 +0200	[thread overview]
Message-ID: <20191017170755.15506ada.cohuck__8127.27809404663$1571324922$gmane$org@redhat.com> (raw)
In-Reply-To: <20191017104836.32464-4-jasowang@redhat.com>

On Thu, 17 Oct 2019 18:48:33 +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.
> 
> Signed-off-by: Jason Wang <jasowang@redhat.com>
> ---
>  .../driver-api/vfio-mediated-device.rst       | 25 +++++----
>  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                 | 18 +++++--
>  drivers/vfio/mdev/mdev_private.h              |  1 +
>  drivers/vfio/mdev/vfio_mdev.c                 | 37 ++++++-------
>  include/linux/mdev.h                          | 45 ++++------------
>  include/linux/vfio_mdev.h                     | 52 +++++++++++++++++++
>  samples/vfio-mdev/mbochs.c                    | 20 ++++---
>  samples/vfio-mdev/mdpy.c                      | 20 ++++---
>  samples/vfio-mdev/mtty.c                      | 18 ++++---
>  13 files changed, 184 insertions(+), 103 deletions(-)
>  create mode 100644 include/linux/vfio_mdev.h
> 
> diff --git a/Documentation/driver-api/vfio-mediated-device.rst b/Documentation/driver-api/vfio-mediated-device.rst
> index f9a78d75a67a..0cca84d19603 100644
> --- a/Documentation/driver-api/vfio-mediated-device.rst
> +++ b/Documentation/driver-api/vfio-mediated-device.rst
> @@ -152,11 +152,22 @@ callbacks per mdev parent device, per mdev type, or any other categorization.
>  Vendor drivers are expected to be fully asynchronous in this respect or
>  provide their own internal resource protection.)
>  
> -The callbacks in the mdev_parent_ops structure are as follows:
> -
> -* open: open callback of mediated device
> -* close: close callback of mediated device
> -* ioctl: ioctl callback of mediated device
> +As multiple types of mediated devices may be supported, the device
> +must set up the class id and the device specific callbacks in create()

s/in create()/in the create()/

> +callback. E.g for vfio-mdev device it needs to be done through:

"Each class provides a helper function to do so; e.g. for vfio-mdev
devices, the function to be called is:"

?

> +
> +    int mdev_set_vfio_ops(struct mdev_device *mdev,
> +                          const struct vfio_mdev_ops *vfio_ops);
> +
> +The class id (set to MDEV_CLASS_ID_VFIO) is used to match a device

"(set by this helper function to MDEV_CLASS_ID_VFIO)" ?

> +with an mdev driver via its id table. The device specific callbacks
> +(specified in *ops) are obtainable via mdev_get_dev_ops() (for use by

"(specified in *vfio_ops by the caller)" ?

> +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
> @@ -167,10 +178,6 @@ register itself with the mdev core driver::
>  	extern int  mdev_register_device(struct device *dev,
>  	                                 const struct mdev_parent_ops *ops);
>  
> -It is also required to specify the class_id in create() callback through::
> -
> -	int mdev_set_class(struct mdev_device *mdev, u16 id);
> -

I'm wondering if this patch set should start out with introducing
helper functions already (i.e. don't introduce mdev_set_class(), but
start out with mdev_set_class_vfio() which will gain the *vfio_ops
argument in this patch.)

>  However, the mdev_parent_ops structure is not required in the function call
>  that a driver should use to unregister itself with the mdev core driver::
>  

(...)

> diff --git a/drivers/vfio/mdev/mdev_core.c b/drivers/vfio/mdev/mdev_core.c
> index 3a9c52d71b4e..d0f3113c8071 100644
> --- a/drivers/vfio/mdev/mdev_core.c
> +++ b/drivers/vfio/mdev/mdev_core.c
> @@ -45,15 +45,23 @@ void mdev_set_drvdata(struct mdev_device *mdev, void *data)
>  }
>  EXPORT_SYMBOL(mdev_set_drvdata);
>  
> -/* Specify the class for the mdev device, this must be called during
> - * create() callback.
> +/* Specify the VFIO device ops for the mdev device, this
> + * must be called during create() callback for VFIO mdev device.
>   */

/*
 * Specify the mdev device to be a VFIO mdev device, and set the
 * VFIO devices ops for it. This must be called from the create()
 * callback for VFIO mdev devices.
 */

?

> -void mdev_set_class(struct mdev_device *mdev, u16 id)
> +void mdev_set_vfio_ops(struct mdev_device *mdev,
> +		       const struct vfio_mdev_device_ops *vfio_ops)
>  {
>  	WARN_ON(mdev->class_id);
> -	mdev->class_id = id;
> +	mdev->class_id = MDEV_CLASS_ID_VFIO;
> +	mdev->device_ops = vfio_ops;
>  }
> -EXPORT_SYMBOL(mdev_set_class);
> +EXPORT_SYMBOL(mdev_set_vfio_ops);
> +
> +const void *mdev_get_dev_ops(struct mdev_device *mdev)
> +{
> +	return mdev->device_ops;
> +}
> +EXPORT_SYMBOL(mdev_get_dev_ops);
>  
>  struct device *mdev_dev(struct mdev_device *mdev)
>  {

(...)

The code change looks good to me; I'm just wondering if we should
introduce mdev_set_class() at all (see above).

  parent reply	other threads:[~2019-10-17 15:07 UTC|newest]

Thread overview: 83+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-17 10:48 [PATCH V4 0/6] mdev based hardware virtio offloading support Jason Wang
2019-10-17 10:48 ` Jason Wang
2019-10-17 10:48 ` [PATCH V4 1/6] mdev: class id support Jason Wang
2019-10-17 10:48   ` Jason Wang
2019-10-20 23:25   ` Parav Pandit
2019-10-20 23:25     ` Parav Pandit
2019-10-20 23:25     ` Parav Pandit
2019-10-17 10:48 ` Jason Wang
2019-10-17 10:48 ` [PATCH V4 2/6] modpost: add support for mdev class id Jason Wang
2019-10-17 10:48   ` Jason Wang
2019-10-20 23:25   ` Parav Pandit
2019-10-20 23:25     ` Parav Pandit
2019-10-20 23:25     ` Parav Pandit
2019-10-17 10:48 ` Jason Wang
2019-10-17 10:48 ` [PATCH V4 3/6] mdev: introduce device specific ops Jason Wang
2019-10-17 10:48 ` Jason Wang
2019-10-17 10:48   ` Jason Wang
2019-10-17 15:07   ` Cornelia Huck
2019-10-17 15:07     ` Cornelia Huck
2019-10-17 17:53     ` Alex Williamson
2019-10-17 17:53       ` Alex Williamson
2019-10-18  7:44       ` Cornelia Huck
2019-10-18  7:44         ` Cornelia Huck
2019-10-17 17:53     ` Alex Williamson
2019-10-18  7:34     ` Jason Wang
2019-10-18  7:34     ` Jason Wang
2019-10-18  7:34       ` Jason Wang
2019-10-17 15:07   ` Cornelia Huck [this message]
2019-10-20 23:41   ` Parav Pandit
2019-10-20 23:41     ` Parav Pandit
2019-10-20 23:41     ` Parav Pandit
2019-10-21  6:02     ` Jason Wang
2019-10-21  6:02     ` Jason Wang
2019-10-21  6:02       ` Jason Wang
2019-10-21  6:02       ` Jason Wang
2019-10-17 10:48 ` [PATCH V4 4/6] mdev: introduce virtio device and its device ops Jason Wang
2019-10-17 10:48   ` Jason Wang
2019-10-17 17:53   ` Alex Williamson
2019-10-17 17:53     ` Alex Williamson
2019-10-18  7:35     ` Jason Wang
2019-10-18  7:35       ` Jason Wang
2019-10-18  7:35     ` Jason Wang
2019-10-17 17:53   ` Alex Williamson
2019-10-18  9:46   ` Cornelia Huck
2019-10-18  9:46   ` Cornelia Huck
2019-10-18  9:46     ` Cornelia Huck
2019-10-18 10:55     ` Jason Wang
2019-10-18 10:55     ` Jason Wang
2019-10-18 10:55       ` Jason Wang
2019-10-18 13:30       ` Cornelia Huck
2019-10-18 13:30         ` Cornelia Huck
2019-10-21  5:36         ` Jason Wang
2019-10-21  5:36         ` Jason Wang
2019-10-21  5:36           ` Jason Wang
2019-10-18 13:30       ` Cornelia Huck
2019-10-18  9:46   ` Tiwei Bie
2019-10-18  9:46     ` Tiwei Bie
2019-10-18 10:57     ` Jason Wang
2019-10-18 10:57       ` Jason Wang
2019-10-18 10:57     ` Jason Wang
2019-10-18  9:46   ` Tiwei Bie
2019-10-17 10:48 ` Jason Wang
2019-10-17 10:48 ` [PATCH V4 5/6] virtio: introduce a mdev based transport Jason Wang
2019-10-17 10:48   ` Jason Wang
2019-10-18 14:20   ` Cornelia Huck
2019-10-18 14:20     ` Cornelia Huck
2019-10-21  5:59     ` Jason Wang
2019-10-21  5:59       ` Jason Wang
2019-10-21  9:36       ` Cornelia Huck
2019-10-21  9:36         ` Cornelia Huck
2019-10-21 10:13         ` Jason Wang
2019-10-21 10:13         ` Jason Wang
2019-10-21 10:13           ` Jason Wang
2019-10-21  9:36       ` Cornelia Huck
2019-10-21  5:59     ` Jason Wang
2019-10-18 14:20   ` Cornelia Huck
2019-10-17 10:48 ` Jason Wang
2019-10-17 10:48 ` [PATCH V4 6/6] docs: sample driver to demonstrate how to implement virtio-mdev framework Jason Wang
2019-10-17 10:48   ` Jason Wang
2019-10-17 10:48 ` Jason Wang
2019-10-17 17:53 ` ✗ Fi.CI.CHECKPATCH: warning for mdev based hardware virtio offloading support (rev5) Patchwork
2019-10-17 18:25 ` ✓ Fi.CI.BAT: success " Patchwork
2019-10-18  3:05 ` ✗ Fi.CI.IGT: failure " Patchwork

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='20191017170755.15506ada.cohuck__8127.27809404663$1571324922$gmane$org@redhat.com' \
    --to=cohuck@redhat.com \
    --cc=airlied@linux.ie \
    --cc=akrowiak@linux.ibm.com \
    --cc=borntraeger@de.ibm.com \
    --cc=christophe.de.dinechin@gmail.com \
    --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=kvm@vger.kernel.org \
    --cc=kwankhede@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=lulu@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=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.