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@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
