On 2019/10/1 上午5:36, Alex Williamson wrote:
On Fri, 27 Sep 2019 16:25:13 +0000
Parav Pandit <parav@xxxxxxxxxxxx> wrote:
Hi Alex,
-----Original Message-----
From: Alex Williamson <alex.williamson@xxxxxxxxxx>
Sent: Tuesday, September 24, 2019 6:07 PM
To: Jason Wang <jasowang@xxxxxxxxxx>
Cc: kvm@xxxxxxxxxxxxxxx; linux-s390@xxxxxxxxxxxxxxx; linux-
kernel@xxxxxxxxxxxxxxx; dri-devel@xxxxxxxxxxxxxxxxxxxxx; intel-
gfx@xxxxxxxxxxxxxxxxxxxxx; intel-gvt-dev@xxxxxxxxxxxxxxxxxxxxx;
kwankhede@xxxxxxxxxx; mst@xxxxxxxxxx; tiwei.bie@xxxxxxxxx;
virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx; netdev@xxxxxxxxxxxxxxx;
cohuck@xxxxxxxxxx; maxime.coquelin@xxxxxxxxxx;
cunming.liang@xxxxxxxxx; zhihong.wang@xxxxxxxxx;
rob.miller@xxxxxxxxxxxx; xiao.w.wang@xxxxxxxxx;
haotian.wang@xxxxxxxxxx; zhenyuw@xxxxxxxxxxxxxxx; zhi.a.wang@xxxxxxxxx;
jani.nikula@xxxxxxxxxxxxxxx; joonas.lahtinen@xxxxxxxxxxxxxxx;
rodrigo.vivi@xxxxxxxxx; airlied@xxxxxxxx; daniel@xxxxxxxx;
farman@xxxxxxxxxxxxx; pasic@xxxxxxxxxxxxx; sebott@xxxxxxxxxxxxx;
oberpar@xxxxxxxxxxxxx; heiko.carstens@xxxxxxxxxx; gor@xxxxxxxxxxxxx;
borntraeger@xxxxxxxxxx; akrowiak@xxxxxxxxxxxxx; freude@xxxxxxxxxxxxx;
lingshan.zhu@xxxxxxxxx; Ido Shamay <idos@xxxxxxxxxxxx>;
eperezma@xxxxxxxxxx; lulu@xxxxxxxxxx; Parav Pandit
<parav@xxxxxxxxxxxx>; christophe.de.dinechin@xxxxxxxxx;
kevin.tian@xxxxxxxxx
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@xxxxxxxxxx> wrote:
This patch implements basic support for mdev driver that supports
virtio transport for kernel virtio driver.
Signed-off-by: Jason Wang <jasowang@xxxxxxxxxx>
---
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
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
