On 2019/9/18 上午10:57, Tian, Kevin wrote:
From: Jason Wang [mailto:jasowang@redhat.com] Sent: Tuesday, September 17, 2019 6:17 PM
On 2019/9/17 下午4:09, Tian, Kevin wrote:
From: Jason Wang Sent: Thursday, September 12, 2019 5:40 PM
Currently, except for the crate and remove. The rest fields of mdev_parent_ops is just designed for vfio-mdev driver and may not
help
for kernel mdev driver. So follow the device id support by previous patch, this patch introduces device specific ops which points to device specific ops (e.g vfio ops). This allows the future drivers like virtio-mdev to implement its own device specific ops.
Can you give an example about what ops might be required to support kernel mdev driver? I know you posted a link earlier, but putting a small example here can save time and avoid inconsistent understanding. Then it will help whether the proposed split makes sense or there is a possibility of redefining the callbacks to meet the both requirements. imo those callbacks fulfill some basic requirements when mediating a device...
I put it in the cover letter.
The link ishttps://lkml.org/lkml/2019/9/10/135 which abuses the current VFIO based mdev parent ops.
Thanks
So the main problem is the handling of userspace pointers vs. kernel space pointers. You still implement read/write/ioctl callbacks which is a subset of current parent_ops definition. In that regard is it better to introduce some helper to handle the pointer difference in mdev core, while still keeping the same set of parent ops (in whatever form suitable for both)?
Pointers is one of the issues. And read/write/ioctl is designed for userspace API not kernel. Technically, we can use them for kernel but it would not be as simple and straightforward a set of device specific callbacks functions. The link above is just an example, e.g we can simply pass the vring address through a dedicated API instead of mandatory an offset of a file.
Thanks