[RFC PATCH v2 0/3] drm/i915/gvt: Enable vGPU local display direct flip

[Zhang, Tina]

> -----Original Message-----
> From: Gerd Hoffmann [mailto:kraxel at redhat.com]
> Sent: Tuesday, May 21, 2019 7:12 PM
> To: Zhang, Tina <tina.zhang at intel.com>
> Cc: 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; Kondapally, Kalyan <kalyan.kondapally at intel.com>; Yuan,
> Hang <hang.yuan at intel.com>; ville.syrjala at linux.intel.com; intel-gvt-
> dev at lists.freedesktop.org
> Subject: Re: [RFC PATCH v2 0/3] drm/i915/gvt: Enable vGPU local display
> direct flip
> 
>   Hi,
> 
> > In-kernel direct flip:
> > ----------------------
> > With "enable_direct_flip" switched on, during vGPU page flip, GVT-g will:
> >
> > 1) Find out the assigned HW planes.
> > GVT-g is the owner of the I915_GEM_OBJECT_IS_PROXY GEM which is
> > exposed by GVT-g with dma-buf interface.
> >
> > GVT-g scan the framebuffers set on the active planes to see if there
> > are some framebuffers with I915_GEM_OBJECT_IS_PROXY GEM.
> >
> > A HW plane using a framebuffer with I915_GEM_OBJECT_IS_PROXY GEM is
> > considered as an assigned plane. GVT-g gets the assignment information
> > through gvt_info structure of the I915_GEM_OBJECT_IS_PROXY GEM.
> >
> > 2) Decode vGPU's framebuffer info and use that to update the shadow
> framebuffer.
> >
> > 3) Commit the shadow framebuffer through "drm_atomic_commit()".
> 
> Hmm, no userspace API included in this patch series.
> 
> The qemu branch has an patch (vfio/display: Interface of querying the fb id
> of vGPU's plane) which isn't documented.
> 
> What is the plan here?
Hi,

The idea is to share the local display HW planes and pipes between VMs. We want to build a flexible mechanism for HW plane assignment and guest framebuffer direct flip.
Currently, the user space interface is our big open now.

In the first version, we proposed to use drm_framebuffer standing for a virtual plane.  Host uses the drm_framebuffer to do the assignment and gvt-g directly commits the guest framebuffer to the assigned plane, which is called in-kernel direct flip. In that proposal we leveraged i915 APIs to do the plane assignment and direct flip. However, we got an open about how to deliver the drm_framebuffer id to the host user space and the idea of adding new ioctls is rejected by upstream. Since the /sys way was also rejected by gvt-g, we began to think about reusing vfio display dma-buf interface for plane assignment.

In this second version, host uses the dma-buf interface to do the assignment and gvt-g direct commits the guest framebuffer to the assigned plane. We didn't introduce any new dma-buf ioctl for this. However gvt-g in kernel does need to know when to start in-kernel direct flip and when to stop. In this proposal, a switch is added to vgpu sys. User space can enable or disable the in-kernel direct flip by echo 1 or 0 to that attribute. And we would like to discuss with user space about this.

Besides, there is also another option: the guest page flip event is delivered to user space where qemu ui can query the dma-buf info and commit the framebuffer based on dma-buf to the HW plane. In this scenario, gvt-g doesn't do the in-kernel direct flip. Everything is handled by host user space (i.e. qemu ui). With the help for drm leasing, qemu ui can fully control the leased pipe and plane resource. And the typical use case is pipe assignment (i.e. each VM is shown on one pipe/monitor). Comments are welcome. 

Thanks.

BR,
Tina



> 
> cheers,
>   Gerd