Messages in this thread | | | Subject | Re: [RFC v4 0/3] vhost: introduce mdev based hardware backend | From | Jason Wang <> | Date | Thu, 19 Sep 2019 21:08:11 +0800 |
| |
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 >> >>
| |