[Intel-gfx] [PATCH v11 1/1] vfio: ABI for mdev display dma-buf operation

Daniel Vetter daniel at ffwll.ch
Wed Jul 12 07:56:11 UTC 2017


On Wed, Jul 12, 2017 at 06:56:53AM +0000, Zhang, Tina wrote:
> 
> 
> > -----Original Message-----
> > From: Zhang, Tina
> > Sent: Wednesday, July 12, 2017 2:11 PM
> > To: alex.williamson at redhat.com; kraxel at redhat.com; chris at chris-wilson.co.uk;
> > zhenyuw at linux.intel.com; Lv, Zhiyuan <zhiyuan.lv at intel.com>; Wang, Zhi A
> > <zhi.a.wang at intel.com>; Tian, Kevin <kevin.tian at intel.com>; daniel at ffwll.ch;
> > kwankhede at nvidia.com
> > Cc: Zhang, Tina <tina.zhang at intel.com>; intel-gfx at lists.freedesktop.org; intel-
> > gvt-dev at lists.freedesktop.org
> > Subject: [PATCH v11 1/1] vfio: ABI for mdev display dma-buf operation
> > 
> > Add VFIO_DEVICE_QUERY_GFX_PLANE ioctl command to let user mode query
> > and get the plan and its related information.
> > 
> > The dma-buf's life cycle is handled by user mode and tracked by kernel.
> > The returned fd in struct vfio_device_query_gfx_plane can be a new fd or an
> > old fd of a re-exported dma-buf. Host User mode can check the value of fd and
> > to see if it needs to create new resource according to the new fd or just use the
> > existed resource related to the old fd.
> > 
> > Signed-off-by: Tina Zhang <tina.zhang at intel.com>
> > 
> > diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h index
> > ae46105..c176cc8 100644
> > --- a/include/uapi/linux/vfio.h
> > +++ b/include/uapi/linux/vfio.h
> > @@ -502,6 +502,32 @@ struct vfio_pci_hot_reset {
> > 
> >  #define VFIO_DEVICE_PCI_HOT_RESET	_IO(VFIO_TYPE, VFIO_BASE + 13)
> > 
> > +/**
> > + * VFIO_DEVICE_QUERY_GFX_PLANE - _IOW(VFIO_TYPE, VFIO_BASE + 14,
> > struct
> > +vfio_device_query_gfx_plane)
> > + *
> > + * Set the drm_plane_type and retrieve information about the gfx plane.
> > + *
> > + * Return: 0 on success, -errno on failure.
> > + */
> > +struct vfio_device_gfx_plane_info {
> > +	__u32 argsz;
> > +	__u32 flags;
> > +	/* in */
> > +	__u32 drm_plane_type;	/* type of plane: DRM_PLANE_TYPE_* */
> > +	/* out */
> > +	__u32 drm_format;	/* drm format of plane */
> > +	__u32 width;	/* width of plane */
> > +	__u32 height;	/* height of plane */
> > +	__u32 stride;	/* stride of plane */
> > +	__u32 size;	/* size of plane in bytes, align on page*/
> > +	__u32 x_pos;	/* horizontal position of cursor plane, upper left corner
> > in pixels */
> > +	__u32 y_pos;	/* vertical position of cursor plane, upper left corner in
> > lines*/
> > +	__s32 fd;	/* dma-buf fd */
> > +};
> > +
> I remove plane_id as I cannot find its meaning for dmabuf usage. Also, I don't know how it could be used by region usage.
> So, if someone can explain its usage, I can add it back. Thanks.
> 
> Another open is, so far, our design is focused on dmabuf based gfx plane only. Can we go a step further to consider a general
> Buffer sharing interface? If we reference V4L2, we can see dmabuf can be considered as one kind of buffers, we can have  more
> kinds of buffers, like mmap buffer and so on. So, if we think about that, we may need another ioctl to ask the mdev device which
> kind of buffer it supports, and then use the VFIO_DEVICE_QUERY_* ioctl to get it back for user mode accessing. Different kinds
> of mdev devices can have different query ioctl name and structure. Is it reasonable?

This is what dma-buf are for. v4l2 also supports dma-buf, and dma-buf
support mmap. I think dma-buf will give you everything you want.

Aside: You're threading is broken somehow, the patch isn't linked to the
cover letter. Not sure what's wrong, I thought latest git gets this right
by default ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


More information about the Intel-gfx mailing list