On 2019/10/1 上午5:36, Alex Williamson wrote:
On Fri, 27 Sep 2019 16:25:13 +0000 Parav Pandit parav@mellanox.com wrote:
Hi Alex,
-----Original Message----- From: Alex Williamson alex.williamson@redhat.com Sent: Tuesday, September 24, 2019 6:07 PM To: Jason Wang jasowang@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; Ido Shamay idos@mellanox.com; eperezma@redhat.com; lulu@redhat.com; Parav Pandit parav@mellanox.com; christophe.de.dinechin@gmail.com; kevin.tian@intel.com Subject: Re: [PATCH V2 6/8] mdev: introduce virtio device and its device ops
On Tue, 24 Sep 2019 21:53:30 +0800 Jason Wang jasowang@redhat.com wrote:
This patch implements basic support for mdev driver that supports virtio transport for kernel virtio driver.
Signed-off-by: Jason Wang jasowang@redhat.com
include/linux/mdev.h | 2 + include/linux/virtio_mdev.h | 145 ++++++++++++++++++++++++++++++++++++ 2 files changed, 147 insertions(+) create mode 100644 include/linux/virtio_mdev.h
diff --git a/include/linux/mdev.h b/include/linux/mdev.h index 3414307311f1..73ac27b3b868 100644 --- a/include/linux/mdev.h +++ b/include/linux/mdev.h @@ -126,6 +126,8 @@ struct mdev_device *mdev_from_dev(struct device *dev);
enum { MDEV_ID_VFIO = 1,
- MDEV_ID_VIRTIO = 2,
- MDEV_ID_VHOST = 3,
MDEV_ID_VHOST isn't used yet here. Also, given the strong interdependence between the class_id and the ops structure, we might wand to define them in the same place. Thanks,
When mlx5_core creates mdevs (parent->ops->create() and it wants to bind to mlx5 mdev driver (which does mdev_register_driver()), mlx5 core driver will publish MDEV_ID_MLX5_NET defined in central place as include/linux/mdev.h without any ops structure. Because such ops are not relevant. It uses usual, standard ops probe() remove() on the mdev (similar to a regular PCI device). So for VHOST case ops may be closely related to ID, but not for other type of ID.
Just want to make sure, that scope of ID covers this case.
AIUI, these device-ops are primarily meant to have 1:N multiplexing of the mdev bus driver. One mdev bus driver supports N vendor drivers via a common "protocol" defined by this structure. vfio-mdev supports GVT-g, GRID, and several sample drivers. I think Jason and Tiwei are attempting something similar if we have multiple vendors that may provide virtio/vhost parent drivers.
Exactly.
If you have a 1:1 model with mlx5 where you're not trying to abstract a common channel between the mdev bus driver and the mdev vendor driver, then I suppose you might not use the device-ops capabilities of the mdev-core.
Yes, current proposed API allows NULL to be passed as device ops.
Thanks
Did I interpret the question correctly? I think that's probably fine, mdev-core shouldn't have any dependencies on the device-ops and we shouldn't really be dictating the bus/vendor link through mdev. Thanks,
Alex