On Tue, Nov 19, 2019 at 10:02:08PM +0800, Jason Wang wrote:
>
> 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.
In the driver model the bus_type and foo_device are closely
linked. Creating 'mdev_device' instances and overriding the bus_type
is a very abusive thing to do.
> 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.
Really, mdev is to support vfio with a backend other than PCI, nothing
more.
Abusing it for other things is not appropriate. ie creating an
instance and not filling in most of the vfio focused ops is an abusive
thing to do.
> 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.
If you need to bind to the VFIO driver then mdev is the right thing to
use, otherwise it is not.
It certainly should not be used to bind to random kernel drivers. This
problem is what this virtual bus idea Intel is working on might solve.
It seems the only thing people care about with mdev is the GUID
lifecycle stuff, but at the same time folks like Parav are saying they
don't want to use that lifecycle stuff and prefer devlink
instead.
Most likely, at least for virtio-net, everyone else will be able to
use devlink as well, making it much less clear if that GUID lifecycle
stuff is a good idea or not.
Jason
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
