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

[Zhang, Tina]

> -----Original Message-----
> From: intel-gvt-dev [mailto:intel-gvt-dev-bounces at lists.freedesktop.org] On
> Behalf Of Gerd Hoffmann
> Sent: Thursday, May 23, 2019 6:50 PM
> To: Zhang, Tina <tina.zhang at intel.com>
> Cc: Tian, Kevin <kevin.tian at intel.com>; zhenyuw at linux.intel.com; Yuan,
> Hang <hang.yuan at intel.com>; ville.syrjala at linux.intel.com; Lv, Zhiyuan
> <zhiyuan.lv at intel.com>; daniel at ffwll.ch; Kondapally, Kalyan
> <kalyan.kondapally at intel.com>; intel-gvt-dev at lists.freedesktop.org; Wang,
> Zhi A <zhi.a.wang at intel.com>
> Subject: Re: [RFC PATCH v2 0/3] drm/i915/gvt: Enable vGPU local display
> direct flip
> 
>   Hi,
> 
> > > So, dmabuf object you'll get is the same thing no matter whenever
> > > the switch is on or off?  But when importing the dmabuf and creating
> > > a drm_framebuffer from it you get traditional framebuffer with the
> > > switch being off and a framebuffer with in-kernel page-flip support
> > > in case the switch is on?
> 
> > The user space can use dmabuf in the traditional way, no matter the
> > switch is on or off. The framebuffer from the drmbuf is different with
> > the one in gvt-g for "in-kernel" direct flip.
> 
> OK.
> 
> > If switch is off, dmabuf thread might be the only thread which can
> > trigger the page filp in user space. If the switch is on, both dmabuf
> > thread in user space and gvt-g in kernel space can trigger the page
> > flip. However, in case of switch=on, dmabuf thread in user space is
> > expected to stop flipping, as gvt-g is doing it faster in kernel.
> 
> Having the switch in sysfs is ok for the proof-of-concept, but long-term we
> need something better.  First, some way to detect whenever the in-kernel
> page-flip is supported or not would be good.  Also I think userspace should
> be able to request the desired behavior when creating the framebuffer.
> Maybe add a flag for drmModeAddFB2WithModifiers()?
> Or use a special modifier?
Not sure. It seems w/o i915's help, it's not easy to provide a nice implementation.

> 
> > > Yes.  drm output shouldn't be hard to wire up.  Handling input will
> > > be a bit more tricky though.
> > How about passing through the input devices to guests? It seems easier.
> 
> drm UI uses libinput.
> 
> When started directly from the console and operating in drm-master mode
> qemu can simply grab all input devices which belong to the seat.
> 
> When running on a drm-lease that would be a bit rude.  Also I don't think
> logind will hand out input file handles in that case.  In case there are
> dedicated input devices for the guest you can use input-linux or usb pass-
> through.  If not, then, hmm, no idea.
We see more and more people would like to use gvt-g to build the intelligent desktop virtualization (IDV) products, where 3 VMs are running with each one having a dedicated monitor, a set of USB keyboard/mouse and one audio card. Since the inputs problem can be solved by passing through the input devices, the most challenge work is how to assign the monitors. Although there are some off-tree solutions (e.g. the proposed the in-kernel direct flip in this patch-set is one of them), people would like to see upstream solutions. I suppose "drm ui + drm lease + pass-through input devices" could be one option. 

And another work, as we discussed, can improve the user experience is to deliver the page flip to user space where qemu ui could leverage to call the ui refresh. 
Here is the RFC version: https://github.com/intel/gvt-linux/commit/9eb50f032d3ebea8d8bfa62e0546dbb8af3b84d9
Can you share your comments about it?
Thanks.

BR,
Tina

> 
> > And the "topic/drm-ui-direct-flip" branch is tracking drm ui branch.
> 
> Cool, thanks, I'll play with that.
> 
> cheers,
>   Gerd
> 
> _______________________________________________
> intel-gvt-dev mailing list
> intel-gvt-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev