Re: [RFC v4 0/3] vhost: introduce mdev based hardware backend

[Jason Wang]

On 2019/9/18 äå10:32, Michael S. Tsirkin wrote:
> > > > So I have some questions:
> > > >
> > > > 1) Compared to method 2, what's the advantage of creating a new vhost char
> > > > device? I guess it's for keep the API compatibility?
> > > One benefit is that we can avoid doing vhost ioctls on
> > > VFIO device fd.
> > Yes, but any benefit from doing this?
> It does seem a bit more modular, but it's certainly not a big deal.


Ok, if we go this way, it could be as simple as provide some callback to 
vhost, then vhost can just forward the ioctl through parent_ops.


> > > > 2) For method 2, is there any easy way for user/admin to distinguish e.g
> > > > ordinary vfio-mdev for vhost from ordinary vfio-mdev?
> > > I think device-api could be a choice.
> > Ok.
> >
> >
> > > > I saw you introduce
> > > > ops matching helper but it's not friendly to management.
> > > The ops matching helper is just to check whether a given
> > > vfio-device is based on a mdev device.
> > >
> > > > 3) A drawback of 1) and 2) is that it must follow vfio_device_ops that
> > > > assumes the parameter comes from userspace, it prevents support kernel
> > > > virtio drivers.
> > > >
> > > > 4) So comes the idea of method 3, since it register a new vhost-mdev driver,
> > > > we can use device specific ops instead of VFIO ones, then we can have a
> > > > common API between vDPA parent and vhost-mdev/virtio-mdev drivers.
> > > As the above draft shows, this requires introducing a new
> > > VFIO device driver. I think Alex's opinion matters here.


Just to clarify, a new type of mdev driver but provides dummy 
vfio_device_ops for VFIO to make container DMA ioctl work.

Thanks


> > Yes, it is.
> >
> > Thanks