[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191015122607.126e3960.cohuck@redhat.com>
Date: Tue, 15 Oct 2019 12:26:07 +0200
From: Cornelia Huck <cohuck@...hat.com>
To: Jason Wang <jasowang@...hat.com>
Cc: kvm@...r.kernel.org, linux-s390@...r.kernel.org,
linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
intel-gfx@...ts.freedesktop.org,
intel-gvt-dev@...ts.freedesktop.org, kwankhede@...dia.com,
alex.williamson@...hat.com, mst@...hat.com, tiwei.bie@...el.com,
virtualization@...ts.linux-foundation.org, netdev@...r.kernel.org,
maxime.coquelin@...hat.com, cunming.liang@...el.com,
zhihong.wang@...el.com, rob.miller@...adcom.com,
xiao.w.wang@...el.com, haotian.wang@...ive.com,
zhenyuw@...ux.intel.com, zhi.a.wang@...el.com,
jani.nikula@...ux.intel.com, joonas.lahtinen@...ux.intel.com,
rodrigo.vivi@...el.com, airlied@...ux.ie, daniel@...ll.ch,
farman@...ux.ibm.com, pasic@...ux.ibm.com, sebott@...ux.ibm.com,
oberpar@...ux.ibm.com, heiko.carstens@...ibm.com,
gor@...ux.ibm.com, borntraeger@...ibm.com, akrowiak@...ux.ibm.com,
freude@...ux.ibm.com, lingshan.zhu@...el.com, idos@...lanox.com,
eperezma@...hat.com, lulu@...hat.com, parav@...lanox.com,
christophe.de.dinechin@...il.com, kevin.tian@...el.com
Subject: Re: [PATCH V3 1/7] mdev: class id support
On Fri, 11 Oct 2019 16:15:51 +0800
Jason Wang <jasowang@...hat.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,
> the first driver could be virtio-mdev. 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
> device with the match method for mdev bus.
>
> Signed-off-by: Jason Wang <jasowang@...hat.com>
> ---
> Documentation/driver-api/vfio-mediated-device.rst | 7 ++++++-
> drivers/gpu/drm/i915/gvt/kvmgt.c | 1 +
> drivers/s390/cio/vfio_ccw_ops.c | 1 +
> drivers/s390/crypto/vfio_ap_ops.c | 1 +
> drivers/vfio/mdev/mdev_core.c | 11 +++++++++++
> 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 | 8 ++++++++
> include/linux/mod_devicetable.h | 8 ++++++++
> samples/vfio-mdev/mbochs.c | 1 +
> samples/vfio-mdev/mdpy.c | 1 +
> samples/vfio-mdev/mtty.c | 1 +
> 13 files changed, 60 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/driver-api/vfio-mediated-device.rst b/Documentation/driver-api/vfio-mediated-device.rst
> index 25eb7d5b834b..2035e48da7b2 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
> @@ -165,12 +167,15 @@ 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::
> +
> + extern int mdev_set_class(struct device *dev, u16 id);
Should the document state explicitly that this should be done in the
->create() callback? Also, I think that the class_id might be different
for different mdevs (even if the parent is the same) -- should that be
mentioned explicitly?
> +
> 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::
>
> extern void mdev_unregister_device(struct device *dev);
>
> -
> Mediated Device Management Interface Through sysfs
> ==================================================
>
(...)
Looks reasonable to me.
Powered by blists - more mailing lists