[Intel-gfx] [PATCH V2 6/8] mdev: introduce virtio device and its device ops

[Jason Wang]

On 2019/10/1 上午5:36, Alex Williamson wrote:
> On Fri, 27 Sep 2019 16:25:13 +0000
> Parav Pandit <parav at mellanox.com> wrote:
>
>> Hi Alex,
>>
>>
>>> -----Original Message-----
>>> From: Alex Williamson <alex.williamson at redhat.com>
>>> Sent: Tuesday, September 24, 2019 6:07 PM
>>> To: Jason Wang <jasowang at redhat.com>
>>> Cc: kvm at vger.kernel.org; linux-s390 at vger.kernel.org; linux-
>>> kernel at vger.kernel.org; dri-devel at lists.freedesktop.org; intel-
>>> gfx at lists.freedesktop.org; intel-gvt-dev at lists.freedesktop.org;
>>> kwankhede at nvidia.com; mst at redhat.com; tiwei.bie at intel.com;
>>> virtualization at lists.linux-foundation.org; netdev at vger.kernel.org;
>>> cohuck at redhat.com; maxime.coquelin at redhat.com;
>>> cunming.liang at intel.com; zhihong.wang at intel.com;
>>> rob.miller at broadcom.com; xiao.w.wang at intel.com;
>>> haotian.wang at sifive.com; zhenyuw at linux.intel.com; zhi.a.wang at intel.com;
>>> jani.nikula at linux.intel.com; joonas.lahtinen at linux.intel.com;
>>> rodrigo.vivi at intel.com; airlied at linux.ie; daniel at ffwll.ch;
>>> farman at linux.ibm.com; pasic at linux.ibm.com; sebott at linux.ibm.com;
>>> oberpar at linux.ibm.com; heiko.carstens at de.ibm.com; gor at linux.ibm.com;
>>> borntraeger at de.ibm.com; akrowiak at linux.ibm.com; freude at linux.ibm.com;
>>> lingshan.zhu at intel.com; Ido Shamay <idos at mellanox.com>;
>>> eperezma at redhat.com; lulu at redhat.com; Parav Pandit
>>> <parav at mellanox.com>; christophe.de.dinechin at gmail.com;
>>> kevin.tian at 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 at 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 at 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