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

[Daniel Vetter]

On Wed, Jul 12, 2017 at 05:48:31PM +0800, Zhenyu Wang wrote:
> On 2017.07.12 09:56:11 +0200, Daniel Vetter wrote:
> > 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.
> >
> 
> yep, I think Tina's point is to how to provide that dmabuf interface
> properly, either in this case for vgpu display specifically or any
> benefit to provide a generic buffer expose/share interface for
> vfio/mdev. But even for vgpu display interface, e.g gvt driver would
> go with dmabuf but nv driver will go with region based, then I don't
> think we could easily have a generic enough design for every mdev type
> or driver. So I believe we should stick with and hopefully get aligned
> for this interface now.

If you expose a dma-buf, you _can_ mmap that thing. Not sure what you mean
with "region", but at least within drm anything that exposes physical
addresses to userspace is not allowed. Only thing you're allowed to do is
have per-process gpu address spaces, because otherwise we can't move stuff
around. Virtualization might be a bit different, but then I'm not clear at
all how exactly this all interacts with nouveau.ko.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch