All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Wang <jasowang@redhat.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: 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,
	rodrigo.vivi@intel.com, xiao.w.wang@intel.com,
	freude@linux.ibm.com, zhenyuw@linux.intel.com,
	parav@mellanox.com, zhihong.wang@intel.com,
	intel-gvt-dev@lists.freedesktop.org, akrowiak@linux.ibm.com,
	oberpar@linux.ibm.com, netdev@vger.kernel.org, cohuck@redhat.com,
	linux-kernel@vger.kernel.org, maxime.coquelin@redhat.com,
	daniel@ffwll.ch
Subject: Re: [PATCH 1/6] mdev: class id support
Date: Tue, 24 Sep 2019 18:11:37 +0800	[thread overview]
Message-ID: <e565c496-7ce8-5889-57c7-7356458c50d5__12141.4298120484$1569319937$gmane$org@redhat.com> (raw)
In-Reply-To: <20190923100529.54568ad8@x1.home>


On 2019/9/24 上午12:05, Alex Williamson wrote:
> On Mon, 23 Sep 2019 21:03:26 +0800
> Jason Wang <jasowang@redhat.com> wrote:
>
>> Mdev bus only supports vfio driver right now, so it doesn't implement
>> match method. But in the future, we may add drivers other than vfio,
>> one example is virtio-mdev[1] driver. This means we need to add device
>> class id support in bus match method to pair the mdev device and mdev
>> driver correctly.
>>
>> So this patch adds id_table to mdev_driver and class_id for mdev
>> parent with the match method for mdev bus.
>>
>> Signed-off-by: Jason Wang <jasowang@redhat.com>
>> ---
>>  Documentation/driver-api/vfio-mediated-device.rst |  7 +++++--
>>  drivers/gpu/drm/i915/gvt/kvmgt.c                  |  2 +-
>>  drivers/s390/cio/vfio_ccw_ops.c                   |  2 +-
>>  drivers/s390/crypto/vfio_ap_ops.c                 |  3 ++-
>>  drivers/vfio/mdev/mdev_core.c                     | 14 ++++++++++++--
>>  drivers/vfio/mdev/mdev_driver.c                   | 14 ++++++++++++++
>>  drivers/vfio/mdev/mdev_private.h                  |  1 +
>>  drivers/vfio/mdev/vfio_mdev.c                     |  6 ++++++
>>  include/linux/mdev.h                              |  7 ++++++-
>>  include/linux/mod_devicetable.h                   |  8 ++++++++
>>  samples/vfio-mdev/mbochs.c                        |  2 +-
>>  samples/vfio-mdev/mdpy.c                          |  2 +-
>>  samples/vfio-mdev/mtty.c                          |  2 +-
>>  13 files changed, 59 insertions(+), 11 deletions(-)
>>
>> diff --git a/Documentation/driver-api/vfio-mediated-device.rst b/Documentation/driver-api/vfio-mediated-device.rst
>> index 25eb7d5b834b..0e052072e1d8 100644
>> --- a/Documentation/driver-api/vfio-mediated-device.rst
>> +++ b/Documentation/driver-api/vfio-mediated-device.rst
>> @@ -102,12 +102,14 @@ structure to represent a mediated device's driver::
>>        * @probe: called when new device created
>>        * @remove: called when device removed
>>        * @driver: device driver structure
>> +      * @id_table: the ids serviced by this driver.
>>        */
>>       struct mdev_driver {
>>  	     const char *name;
>>  	     int  (*probe)  (struct device *dev);
>>  	     void (*remove) (struct device *dev);
>>  	     struct device_driver    driver;
>> +	     const struct mdev_class_id *id_table;
>>       };
>>  
>>  A mediated bus driver for mdev should use this structure in the function calls
>> @@ -116,7 +118,7 @@ to register and unregister itself with the core driver:
>>  * Register::
>>  
>>      extern int  mdev_register_driver(struct mdev_driver *drv,
>> -				   struct module *owner);
>> +                                     struct module *owner);
>>  
>>  * Unregister::
>>  
>> @@ -163,7 +165,8 @@ A driver should use the mdev_parent_ops structure in the function call to
>>  register itself with the mdev core driver::
>>  
>>  	extern int  mdev_register_device(struct device *dev,
>> -	                                 const struct mdev_parent_ops *ops);
>> +	                                 const struct mdev_parent_ops *ops,
>> +	                                 u8 class_id);
>>  
>>  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/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
>> index 23aa3e50cbf8..19d51a35f019 100644
>> --- a/drivers/gpu/drm/i915/gvt/kvmgt.c
>> +++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
>> @@ -1625,7 +1625,7 @@ static int kvmgt_host_init(struct device *dev, void *gvt, const void *ops)
>>  		return -EFAULT;
>>  	intel_vgpu_ops.supported_type_groups = kvm_vgpu_type_groups;
>>  
>> -	return mdev_register_device(dev, &intel_vgpu_ops);
>> +	return mdev_register_vfio_device(dev, &intel_vgpu_ops);
>>  }
>>  
>>  static void kvmgt_host_exit(struct device *dev)
>> diff --git a/drivers/s390/cio/vfio_ccw_ops.c b/drivers/s390/cio/vfio_ccw_ops.c
>> index f0d71ab77c50..246ff0f80944 100644
>> --- a/drivers/s390/cio/vfio_ccw_ops.c
>> +++ b/drivers/s390/cio/vfio_ccw_ops.c
>> @@ -588,7 +588,7 @@ static const struct mdev_parent_ops vfio_ccw_mdev_ops = {
>>  
>>  int vfio_ccw_mdev_reg(struct subchannel *sch)
>>  {
>> -	return mdev_register_device(&sch->dev, &vfio_ccw_mdev_ops);
>> +	return mdev_register_vfio_device(&sch->dev, &vfio_ccw_mdev_ops);
>>  }
>>  
>>  void vfio_ccw_mdev_unreg(struct subchannel *sch)
>> diff --git a/drivers/s390/crypto/vfio_ap_ops.c b/drivers/s390/crypto/vfio_ap_ops.c
>> index 5c0f53c6dde7..7487fc39d2c5 100644
>> --- a/drivers/s390/crypto/vfio_ap_ops.c
>> +++ b/drivers/s390/crypto/vfio_ap_ops.c
>> @@ -1295,7 +1295,8 @@ int vfio_ap_mdev_register(void)
>>  {
>>  	atomic_set(&matrix_dev->available_instances, MAX_ZDEV_ENTRIES_EXT);
>>  
>> -	return mdev_register_device(&matrix_dev->device, &vfio_ap_matrix_ops);
>> +	return mdev_register_vfio_device(&matrix_dev->device,
>> +					 &vfio_ap_matrix_ops);
>>  }
>>  
>>  void vfio_ap_mdev_unregister(void)
>> diff --git a/drivers/vfio/mdev/mdev_core.c b/drivers/vfio/mdev/mdev_core.c
>> index b558d4cfd082..a02c256a3514 100644
>> --- a/drivers/vfio/mdev/mdev_core.c
>> +++ b/drivers/vfio/mdev/mdev_core.c
>> @@ -135,11 +135,14 @@ static int mdev_device_remove_cb(struct device *dev, void *data)
>>   * mdev_register_device : Register a device
>>   * @dev: device structure representing parent device.
>>   * @ops: Parent device operation structure to be registered.
>> + * @id: device id.
>>   *
>>   * Add device to list of registered parent devices.
>>   * Returns a negative value on error, otherwise 0.
>>   */
>> -int mdev_register_device(struct device *dev, const struct mdev_parent_ops *ops)
>> +int mdev_register_device(struct device *dev,
>> +			 const struct mdev_parent_ops *ops,
>> +			 u8 class_id)
>>  {
>>  	int ret;
>>  	struct mdev_parent *parent;
>> @@ -175,6 +178,7 @@ int mdev_register_device(struct device *dev, const struct mdev_parent_ops *ops)
>>  
>>  	parent->dev = dev;
>>  	parent->ops = ops;
>> +	parent->class_id = class_id;
>>  
> I don't think we want to tie the class_id to the parent.  mdev parent
> devices can create various types of devices, some might be virtio, some
> might be vfio.  I think the cover letter even suggests that's a
> direction these virtio devices might be headed.  It seems the class
> should be on the resulting device itself.  That also suggests that at
> the parent we cannot have a single device_ops, the ops used will depend
> on the type of device created.  Perhaps that means we need vfio_ops
> alongside virtio_ops, rather than a common device_ops.  Thanks,
>
> Alex
>

Yes, will do it in V2.

Thanks

_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

  parent reply	other threads:[~2019-09-24 10:11 UTC|newest]

Thread overview: 76+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-23 13:03 [PATCH 0/6] mdev based hardware virtio offloading support Jason Wang
2019-09-23 13:03 ` [PATCH 1/6] mdev: class id support Jason Wang
2019-09-23 13:03 ` Jason Wang
2019-09-23 13:03   ` Jason Wang
2019-09-23 16:05   ` Alex Williamson
2019-09-23 16:05   ` Alex Williamson
2019-09-23 16:05     ` Alex Williamson
2019-09-24 10:11     ` Jason Wang
2019-09-24 10:11       ` Jason Wang
2019-09-24 10:11     ` Jason Wang [this message]
2019-09-23 20:58   ` Parav Pandit
2019-09-23 20:58     ` Parav Pandit
2019-09-23 20:58     ` Parav Pandit
2019-09-24 11:20     ` Jason Wang
2019-09-24 11:20       ` Jason Wang
2019-09-24 11:20       ` Jason Wang
2019-09-24 11:20     ` Jason Wang
2019-09-23 21:02   ` Parav Pandit
2019-09-23 21:02     ` Parav Pandit
2019-09-23 21:02     ` Parav Pandit
2019-09-24 11:23     ` Jason Wang
2019-09-24 11:23     ` Jason Wang
2019-09-24 11:23       ` Jason Wang
2019-09-24 11:23       ` Jason Wang
2019-09-23 13:03 ` [PATCH 2/6] mdev: introduce device specific ops Jason Wang
2019-09-23 15:20   ` kbuild test robot
2019-09-23 15:20     ` kbuild test robot
2019-09-23 15:20     ` kbuild test robot
2019-09-23 15:36     ` Michael S. Tsirkin
2019-09-23 15:36     ` Michael S. Tsirkin
2019-09-23 15:36       ` Michael S. Tsirkin
2019-09-24 11:23       ` Jason Wang
2019-09-24 11:23         ` Jason Wang
2019-09-24 11:23       ` Jason Wang
2019-09-23 15:20   ` kbuild test robot
2019-09-23 22:59   ` Parav Pandit
2019-09-23 22:59     ` Parav Pandit
2019-09-23 22:59     ` Parav Pandit
2019-09-24 11:26     ` Jason Wang
2019-09-24 11:26       ` Jason Wang
2019-09-24 11:26       ` Jason Wang
2019-09-24 11:26     ` Jason Wang
2019-09-23 13:03 ` Jason Wang
2019-09-23 13:03 ` [PATCH 3/6] mdev: introduce virtio device and its device ops Jason Wang
2019-09-23 13:03 ` Jason Wang
2019-09-23 13:03 ` [PATCH 4/6] virtio: introduce a mdev based transport Jason Wang
2019-09-23 13:03 ` Jason Wang
2019-09-23 22:28   ` Parav Pandit
2019-09-23 22:28     ` Parav Pandit
2019-09-23 22:28     ` Parav Pandit
2019-09-24 11:30     ` Jason Wang
2019-09-24 11:30       ` Jason Wang
2019-09-24 11:30       ` Jason Wang
2019-09-24 11:30     ` Jason Wang
2019-09-23 13:03 ` [PATCH 5/6] vringh: fix copy direction of vringh_iov_push_kern() Jason Wang
2019-09-23 13:03   ` Jason Wang
2019-09-23 15:45   ` Alex Williamson
2019-09-23 15:45   ` Alex Williamson
2019-09-23 15:45     ` Alex Williamson
2019-09-23 16:00     ` Michael S. Tsirkin
2019-09-23 16:00     ` Michael S. Tsirkin
2019-09-23 16:00       ` Michael S. Tsirkin
2019-09-24 14:04       ` Alex Williamson
2019-09-24 14:04         ` Alex Williamson
2019-09-25 11:56         ` Jason Wang
2019-09-25 11:56         ` Jason Wang
2019-09-25 11:56           ` Jason Wang
2019-09-24 14:04       ` Alex Williamson
2019-09-23 13:03 ` [PATCH 6/6] docs: sample driver to demonstrate how to implement virtio-mdev framework Jason Wang
2019-09-23 13:03 ` Jason Wang
2019-09-23 13:59 ` [PATCH 0/6] mdev based hardware virtio offloading support Michael S. Tsirkin
2019-09-23 13:59   ` Michael S. Tsirkin
2019-09-23 13:59 ` Michael S. Tsirkin
2019-09-23 18:22 ` ✗ Fi.CI.CHECKPATCH: warning for mdev based hardware virtio offloading support (rev2) Patchwork
2019-09-23 18:44 ` ✓ Fi.CI.BAT: success " Patchwork
2019-09-24  6:07 ` ✓ Fi.CI.IGT: " 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='e565c496-7ce8-5889-57c7-7356458c50d5__12141.4298120484$1569319937$gmane$org@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=cohuck@redhat.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=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.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=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.