From: Jason Wang <jasowang@redhat.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: 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, cohuck@redhat.com,
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
Subject: Re: [PATCH V2 5/8] mdev: introduce device specific ops
Date: Wed, 25 Sep 2019 20:04:54 +0800 [thread overview]
Message-ID: <27a9a71f-5a10-77be-2f54-5af52a406a00@redhat.com> (raw)
In-Reply-To: <20190924170638.064d85f7@x1.home>
On 2019/9/25 上午7:06, Alex Williamson wrote:
> On Tue, 24 Sep 2019 21:53:29 +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 | 4 +-
>> MAINTAINERS | 1 +
>> drivers/gpu/drm/i915/gvt/kvmgt.c | 17 +++---
>> drivers/s390/cio/vfio_ccw_ops.c | 17 ++++--
>> drivers/s390/crypto/vfio_ap_ops.c | 13 +++--
>> drivers/vfio/mdev/mdev_core.c | 12 +++++
>> drivers/vfio/mdev/mdev_private.h | 1 +
>> drivers/vfio/mdev/vfio_mdev.c | 37 ++++++-------
>> include/linux/mdev.h | 42 ++++-----------
>> include/linux/vfio_mdev.h | 52 +++++++++++++++++++
>> samples/vfio-mdev/mbochs.c | 19 ++++---
>> samples/vfio-mdev/mdpy.c | 19 ++++---
>> samples/vfio-mdev/mtty.c | 17 ++++--
>> 13 files changed, 168 insertions(+), 83 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 a5bdc60d62a1..d50425b368bb 100644
>> --- a/Documentation/driver-api/vfio-mediated-device.rst
>> +++ b/Documentation/driver-api/vfio-mediated-device.rst
>> @@ -152,7 +152,9 @@ 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:
>> +The device specific callbacks are referred through device_ops pointer
>> +in mdev_parent_ops. For vfio-mdev device, its callbacks in device_ops
>> +are as follows:
> This is not accurate. device_ops is now on the mdev_device and is an
> mdev bus driver specific structure of callbacks that must be registered
> for each mdev device by the parent driver during the create callback.
> There's a one to one mapping of class_id to mdev_device_ops callbacks.
Yes.
>
> That also suggests to me that we could be more clever in registering
> both of these with mdev-core. Can we embed the class_id in the ops
> structure in a common way so that the core can extract it and the bus
> drivers can access their specific callbacks?
That seems much cleaner, let me try to do that in V3.
>
>> * open: open callback of mediated device
>> * close: close callback of mediated device
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index b2326dece28e..89832b316500 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -17075,6 +17075,7 @@ S: Maintained
>> F: Documentation/driver-api/vfio-mediated-device.rst
>> F: drivers/vfio/mdev/
>> F: include/linux/mdev.h
>> +F: include/linux/vfio_mdev.h
>> F: samples/vfio-mdev/
>>
>> VFIO PLATFORM DRIVER
>> diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
>> index f793252a3d2a..b274f5ee481f 100644
>> --- a/drivers/gpu/drm/i915/gvt/kvmgt.c
>> +++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
>> @@ -42,6 +42,7 @@
>> #include <linux/kvm_host.h>
>> #include <linux/vfio.h>
>> #include <linux/mdev.h>
>> +#include <linux/vfio_mdev.h>
>> #include <linux/debugfs.h>
>>
>> #include <linux/nospec.h>
>> @@ -643,6 +644,8 @@ static void kvmgt_put_vfio_device(void *vgpu)
>> vfio_device_put(((struct intel_vgpu *)vgpu)->vdev.vfio_device);
>> }
>>
>> +static struct vfio_mdev_device_ops intel_vfio_vgpu_dev_ops;
>> +
>> static int intel_vgpu_create(struct kobject *kobj, struct mdev_device *mdev)
>> {
>> struct intel_vgpu *vgpu = NULL;
>> @@ -679,6 +682,7 @@ static int intel_vgpu_create(struct kobject *kobj, struct mdev_device *mdev)
>> ret = 0;
>>
>> mdev_set_class_id(mdev, MDEV_ID_VFIO);
>> + mdev_set_dev_ops(mdev, &intel_vfio_vgpu_dev_ops);
> This seems rather unrefined. We're registering interdependent data in
> separate calls. All drivers need to make both of these calls. I'm not
> sure if this is a good idea, but what if we had:
>
> static const struct vfio_mdev_device_ops intel_vfio_vgpu_dev_ops = {
> .id = MDEV_ID_VFIO,
> .open = intel_vgpu_open,
> .release = intel_vgpu_release,
> ...
>
> And the set function passed &intel_vfio_vgpu_dev_ops.id and the mdev
> bus drivers used container_of to get to their callbacks?
Yes, with the check of mdev_device_create() if nothing is set by the device.
>
>> out:
>> return ret;
>> }
>> @@ -1601,20 +1605,21 @@ static const struct attribute_group *intel_vgpu_groups[] = {
>> NULL,
>> };
>>
>> -static struct mdev_parent_ops intel_vgpu_ops = {
>> - .mdev_attr_groups = intel_vgpu_groups,
>> - .create = intel_vgpu_create,
>> - .remove = intel_vgpu_remove,
>> -
>> +static struct vfio_mdev_device_ops intel_vfio_vgpu_dev_ops = {
>> .open = intel_vgpu_open,
>> .release = intel_vgpu_release,
>> -
>> .read = intel_vgpu_read,
>> .write = intel_vgpu_write,
>> .mmap = intel_vgpu_mmap,
>> .ioctl = intel_vgpu_ioctl,
>> };
>>
>> +static struct mdev_parent_ops intel_vgpu_ops = {
> These could maybe be made const at the same time. Thanks,
>
> Alex
Ok, let me fix.
Thanks
next prev parent reply other threads:[~2019-09-25 12:06 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-24 13:53 [PATCH V2 0/8] mdev based hardware virtio offloading support Jason Wang
2019-09-24 13:53 ` [PATCH V2 1/8] vringh: fix copy direction of vringh_iov_push_kern() Jason Wang
2019-09-24 13:53 ` [PATCH V2 2/8] mdev: class id support Jason Wang
2019-09-24 23:06 ` Alex Williamson
2019-09-25 12:01 ` Jason Wang
2019-09-25 8:28 ` Tian, Kevin
2019-09-25 12:13 ` Jason Wang
2019-09-24 13:53 ` [PATCH V2 3/8] mdev: bus uevent support Jason Wang
2019-09-24 13:53 ` [PATCH V2 4/8] modpost: add support for mdev class id Jason Wang
2019-09-24 13:53 ` [PATCH V2 5/8] mdev: introduce device specific ops Jason Wang
2019-09-24 23:06 ` Alex Williamson
2019-09-25 12:04 ` Jason Wang [this message]
2019-09-24 13:53 ` [PATCH V2 6/8] mdev: introduce virtio device and its device ops Jason Wang
2019-09-24 23:06 ` Alex Williamson
2019-09-25 12:06 ` Jason Wang
2019-09-27 8:37 ` Jason Wang
2019-10-10 9:18 ` Jason Wang
2019-09-25 9:09 ` Tian, Kevin
2019-09-25 12:45 ` Jason Wang
2019-09-26 0:48 ` Tian, Kevin
2019-09-26 8:12 ` Jason Wang
2019-09-24 13:53 ` [PATCH V2 7/8] virtio: introduce a mdev based transport Jason Wang
2019-09-24 13:53 ` [PATCH V2 8/8] docs: sample driver to demonstrate how to implement virtio-mdev framework Jason Wang
2019-09-25 8:24 ` [PATCH V2 0/8] mdev based hardware virtio offloading support Tian, Kevin
2019-09-25 12:13 ` 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=27a9a71f-5a10-77be-2f54-5af52a406a00@redhat.com \
--to=jasowang@redhat.com \
--cc=airlied@linux.ie \
--cc=akrowiak@linux.ibm.com \
--cc=alex.williamson@redhat.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=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=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).