All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Wang <jasowang@redhat.com>
To: Cornelia Huck <cohuck@redhat.com>
Cc: 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.coquelin@redhat.comda
Subject: Re: [PATCH V3 4/7] mdev: introduce device specific ops
Date: Tue, 15 Oct 2019 20:17:01 +0800	[thread overview]
Message-ID: <eb7ecd99-7465-6be4-7ecd-84c11f66e0ac__13397.0799901121$1571141868$gmane$org@redhat.com> (raw)
In-Reply-To: <20191015124137.4f948bd2.cohuck@redhat.com>


On 2019/10/15 下午6:41, Cornelia Huck wrote:
> On Fri, 11 Oct 2019 16:15:54 +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       | 22 +++++---
>>   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                 |  9 +++-
>>   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                    | 20 ++++---
>>   samples/vfio-mdev/mdpy.c                      | 21 +++++---
>>   samples/vfio-mdev/mtty.c                      | 18 ++++---
>>   13 files changed, 177 insertions(+), 96 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 2035e48da7b2..553574ebba73 100644
>> --- a/Documentation/driver-api/vfio-mediated-device.rst
>> +++ b/Documentation/driver-api/vfio-mediated-device.rst
>> @@ -152,11 +152,20 @@ 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:
>> +In order to support multiple types of device/driver, device needs to
>> +provide both class_id and device_ops through:
> "As multiple types of mediated devices may be supported, the device
> needs to set up the class id and the device specific callbacks via:"
>
> ?
>
>>   
>> -* open: open callback of mediated device
>> -* close: close callback of mediated device
>> -* ioctl: ioctl callback of mediated device
>> +    void mdev_set_class(struct mdev_device *mdev, u16 id, const void *ops);
>> +
>> +The class_id is used to be paired with ids in id_table in mdev_driver
>> +structure for probing the correct driver.
> "The class id  (specified in id) is used to match a device with an mdev
> driver via its id table."
>
> ?
>
>> The device_ops is device
>> +specific callbacks which can be get through mdev_get_dev_ops()
>> +function by mdev bus driver.
> "The device specific callbacks (specified in *ops) are obtainable via
> mdev_get_dev_ops() (for use by the mdev bus driver.)"
>
> ?
>
>> For vfio-mdev device, its device specific
>> +ops are as follows:
> "A vfio-mdev device (class id MDEV_ID_VFIO) uses the following
> device-specific ops:"
>
> ?


All you propose is better than what I wrote, will change the docs.


>
>> +
>> +* 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,9 +176,10 @@ 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 through::
>> +It is also required to specify the class_id and device specific ops through::
>>   
>> -	extern int mdev_set_class(struct device *dev, u16 id);
>> +	extern int mdev_set_class(struct device *dev, u16 id,
>> +	                          const void *ops);
> Apologies if that has already been discussed, but do we want a 1:1
> relationship between id and ops, or can different devices with the same
> id register different ops?


I think we have a N:1 mapping between id and ops, e.g we want both 
virtio-mdev and vhost-mdev use a single set of device ops.

Thanks


> If the former, would it make sense to first
> register the ops for an id (once), and then have the ->create callback
> only set the class id (with the core doing the lookup of the ops)?
>
>>   
>>   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::
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

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

Thread overview: 105+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-11  8:15 [PATCH V3 0/7] mdev based hardware virtio offloading support Jason Wang
2019-10-11  8:15 ` Jason Wang
2019-10-11  8:15 ` [PATCH V3 1/7] mdev: class id support Jason Wang
2019-10-11  8:15 ` Jason Wang
2019-10-11  8:15   ` Jason Wang
2019-10-15 10:26   ` Cornelia Huck
2019-10-15 10:26   ` Cornelia Huck
2019-10-15 10:26     ` Cornelia Huck
2019-10-15 12:12     ` Jason Wang
2019-10-15 12:12       ` Jason Wang
2019-10-15 12:12     ` Jason Wang
2019-10-15 16:38   ` Alex Williamson
2019-10-15 16:38     ` Alex Williamson
2019-10-16  4:38     ` Jason Wang
2019-10-16  4:38       ` Jason Wang
2019-10-16  4:38     ` Jason Wang
2019-10-15 16:38   ` Alex Williamson
2019-10-16  4:57   ` Parav Pandit
2019-10-16  4:57     ` Parav Pandit
2019-10-16  4:57     ` Parav Pandit
2019-10-16 10:37     ` Jason Wang
2019-10-16 10:37       ` Jason Wang
2019-10-16 10:37       ` Jason Wang
2019-10-16 10:37     ` Jason Wang
2019-10-17  8:27     ` Jason Wang
2019-10-17  8:27       ` Jason Wang
2019-10-17  8:27       ` Jason Wang
2019-10-17  8:27     ` Jason Wang
2019-10-11  8:15 ` [PATCH V3 2/7] mdev: bus uevent support Jason Wang
2019-10-11  8:15   ` Jason Wang
2019-10-15 10:27   ` Cornelia Huck
2019-10-15 10:27     ` Cornelia Huck
2019-10-15 12:13     ` Jason Wang
2019-10-15 12:13     ` Jason Wang
2019-10-15 12:13       ` Jason Wang
2019-10-15 10:27   ` Cornelia Huck
2019-10-16  5:06   ` Parav Pandit
2019-10-16  5:06     ` Parav Pandit
2019-10-16  5:06     ` Parav Pandit
2019-10-11  8:15 ` Jason Wang
2019-10-11  8:15 ` [PATCH V3 3/7] modpost: add support for mdev class id Jason Wang
2019-10-11  8:15   ` Jason Wang
2019-10-11  8:15 ` Jason Wang
2019-10-11  8:15 ` [PATCH V3 4/7] mdev: introduce device specific ops Jason Wang
2019-10-11  8:15 ` Jason Wang
2019-10-11  8:15   ` Jason Wang
2019-10-15 10:41   ` Cornelia Huck
2019-10-15 10:41     ` Cornelia Huck
2019-10-15 12:17     ` Jason Wang [this message]
2019-10-15 12:17     ` Jason Wang
2019-10-15 12:17       ` Jason Wang
2019-10-15 17:26       ` Alex Williamson
2019-10-15 17:26       ` Alex Williamson
2019-10-15 17:26         ` Alex Williamson
2019-10-16  5:50         ` Parav Pandit
2019-10-16  8:52           ` Cornelia Huck
2019-10-16 15:31             ` Parav Pandit
2019-10-16 16:53               ` Alex Williamson
2019-10-16 20:48                 ` Parav Pandit
2019-10-16 22:37                   ` Alex Williamson
2019-10-17 16:29                     ` Parav Pandit
2019-10-17  8:30                 ` Jason Wang
2019-10-17  8:30                 ` Jason Wang
2019-10-17  8:45                   ` Cornelia Huck
2019-10-17  8:46                     ` Jason Wang
2019-10-17  8:46                     ` Jason Wang
2019-10-16 16:53               ` Alex Williamson
2019-10-15 10:41   ` Cornelia Huck
2019-10-11  8:15 ` [PATCH V3 5/7] mdev: introduce virtio device and its device ops Jason Wang
2019-10-11  8:15   ` Jason Wang
2019-10-14 17:23   ` Stefan Hajnoczi
2019-10-14 17:23     ` Stefan Hajnoczi
2019-10-15  3:27     ` Jason Wang
2019-10-15  3:27       ` Jason Wang
2019-10-15  3:27     ` Jason Wang
2019-10-14 17:23   ` Stefan Hajnoczi
2019-10-11  8:15 ` Jason Wang
2019-10-11  8:15 ` [PATCH V3 6/7] virtio: introduce a mdev based transport Jason Wang
2019-10-11  8:15   ` Jason Wang
2019-10-14 17:39   ` Stefan Hajnoczi
2019-10-14 17:39     ` Stefan Hajnoczi
2019-10-15  3:29     ` Jason Wang
2019-10-15  3:29       ` Jason Wang
2019-10-11  8:15 ` Jason Wang
2019-10-11  8:15 ` [PATCH V3 7/7] docs: sample driver to demonstrate how to implement virtio-mdev framework Jason Wang
2019-10-11  8:15 ` Jason Wang
2019-10-11  8:15   ` Jason Wang
2019-10-11  9:26 ` ✗ Fi.CI.CHECKPATCH: warning for mdev based hardware virtio offloading support (rev4) Patchwork
2019-10-11 10:03 ` ✓ Fi.CI.BAT: success " Patchwork
2019-10-11 17:40 ` ✓ Fi.CI.IGT: " Patchwork
2019-10-14 17:49 ` [PATCH V3 0/7] mdev based hardware virtio offloading support Stefan Hajnoczi
2019-10-14 17:49 ` Stefan Hajnoczi
2019-10-14 17:49   ` Stefan Hajnoczi
2019-10-15  3:37   ` Jason Wang
2019-10-15  3:37   ` Jason Wang
2019-10-15  3:37     ` Jason Wang
2019-10-15 14:37     ` Stefan Hajnoczi
2019-10-15 14:37     ` Stefan Hajnoczi
2019-10-15 14:37       ` Stefan Hajnoczi
2019-10-17  1:42       ` Jason Wang
2019-10-17  1:42       ` Jason Wang
2019-10-17  1:42         ` Jason Wang
2019-10-17  9:43         ` Stefan Hajnoczi
2019-10-17  9:43         ` Stefan Hajnoczi
2019-10-17  9:43           ` Stefan Hajnoczi

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='eb7ecd99-7465-6be4-7ecd-84c11f66e0ac__13397.0799901121$1571141868$gmane$org@redhat.com' \
    --to=jasowang@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=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=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=maxime.coquelin@redhat.comda \
    --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=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.