On 2019/9/18 上午10:57, Tian, Kevin wrote:
From: Jason Wang [mailto:jasowang@xxxxxxxxxx]
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
