Re: [PATCH V13 4/6] mdev: introduce mediated virtio bus

[Jason Wang <jasowang@redhat.com>]

On 2019/11/19 下午8:38, Jason Gunthorpe wrote:
> On Tue, Nov 19, 2019 at 10:41:31AM +0800, Jason Wang wrote:
>> On 2019/11/19 上午4:28, Jason Gunthorpe wrote:
>>> On Mon, Nov 18, 2019 at 03:27:13PM -0500, Michael S. Tsirkin wrote:
>>>> On Mon, Nov 18, 2019 at 01:41:00PM +0000, Jason Gunthorpe wrote:
>>>>> On Mon, Nov 18, 2019 at 06:59:21PM +0800, Jason Wang wrote:
>>>>>> +struct bus_type mdev_virtio_bus_type;
>>>>>> +
>>>>>> +struct mdev_virtio_device {
>>>>>> +	struct mdev_device mdev;
>>>>>> +	const struct mdev_virtio_ops *ops;
>>>>>> +	u16 class_id;
>>>>>> +};
>>>>> This seems to share nothing with mdev (ie mdev-vfio), why is it on the
>>>>> same bus?
>>>> I must be missing something - which bus do they share?
>>> mdev_bus_type ?
>>>
>>> Jason
>>
>> Note: virtio has its own bus: mdev_virtio_bus_type. So they are not the same
>> bus.
> That is even worse, why involve struct mdev_device at all then?
>
> Jason


I don't quite get the question here.

My understanding for mdev is that it was a mediator between the driver 
and physical device when it's hard to let them talk directly due to the 
complexity of refactoring and maintenance. This is exact the case of 
hardware that can offload virtio datapath but not control path. We want 
to present a unified interface (standard virtio) instead of a vendor 
specific interface, so a mediator level in the middle is a must. For 
virtio driver, mediator present a full virtio compatible device. For 
hardware, mediator will mediate the difference between the behavior 
defined by virtio spec and real hardware.

And the reason why not inventing something new instead of existed mdev 
is because mdev fits into the requirement of virtio-mdev very well:
1) mature framework which has been used by vGPU and other type for years
2) life cycle interface, have a unified interface for management instead 
of a vendor specific one so less pain for management
3) device type management. In the case of virtio, user can choose to 
create a vhost type of device or virtio type of device, or technically 
it can choose which version or features of virtio device it want to create.
4) IOMMU support, mdev allows DMA isolation done at either parent level 
or platform/bus level
5) vendor specific attributes

So in Parav's thread [1], if I understand correctly.  The major concern 
is the  API multiplexer at a single mdev bus level. So comes to this 
series which decouple VFIO and make mdev more generic to be suitable for 
implementing a set of independent buses with similar functions.

Thanks

[1] https://www.spinics.net/lists/linux-rdma/msg85856.html

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel