[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: Wednesday, May 22, 2019 3:40 AM
> 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,
> 
> > 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.
> 
> I remember those discussions.  So this approach isn't used any more.
> That clarifies things a bit.
> 
> > 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.
> 
> So, what happens exactly?  With the sysfs switch disabled you'll probably get
> traditional behavior, i.e. dmabufs are exported via vfio API, and it changes on
> each page flip.
The sysfs switch only means who is in charge of the page flip. So, yes, if the sysfs switch disabled, it means the traditional behavior which is supported by upstream. UIs based on dma-buf has to poll periodically to get the new framebuffer from guest and use that framebuffer to do rendering or display.
 
> 
> Now with the switch enabled, what changes?  Userspace will still get a
> dmabuf I guess, but probably not a new one on each page flip.
Actually this switch is only for display not rendering. 

We're asked to support the use case that the guest's framebuffer is flipped to the display monitor w/o the help of host window manager or compositor. So, in this sensorial the guest's framebuffer is shown in full-screen view. Since SKL PC has three pipes, technically we can support three VMs to separately flip their framebuffers to the three different monitors.

Why host window manager or compositor isn't desired in this use case?
It's believed it's hard to implement the static full-screen mode (i.e. during one VM's life cycle, the VM desktop is statically shown on a monitor) on the display monitor controlled by host window manager.

But VM does need someone in host side to flip its framebuffers to the assigned display monitor. That's why this switch is introduced. When the switch is on, gvt-g will flip the guest framebuffers to the assigned planes, which is called in-kernel direct flip. And the vfio display dma-buf APIs are reuse here in this patch-set to do the plane assignment.

How to assign a plane to a VM?
First, user space needs to get a framebuffer based on dma-buf through the vfio display dma-buf APIs. Then, user space imports this dma-buf and makes it into a drm_framebuffer by using drm APIs. At last, user space uses mode setting or plane setting drm/kms APIs to attach the framebuffer to a physical which is called plane assignment. Although w/ switch on this is the only desired user space behavior, the implementation doesn't block user space from using dma-buf interface in the traditional behavior.

> 
> Can userspace mmap() the dmabuf?
No.

> 
> Can userspace import the dmabuf as egl image, then use it as texture or
> framebuffer?
No. 

> 
> Can userspace import the dmabuf as bo (using gbm_import_bo() for
> example), create a drm framebuffer and map it to a crtc?
Yes. W/ switch on, this is called plane assignment. 

> 
> Will the content update automatically on pageflips?
Yes, this is fulfilled by gvt-g in kernel.

> 
> > 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).
> 
> Initial sketch of a drm ui:
>   https://git.kraxel.org/cgit/qemu/log/?h=sirius/display-drm
Just did quick review. Nice job :-)

> 
> Does exactly this.  In polling mode though.  The kernel delivering a guest
> page-flip notification to qemu somehow would be useful for a timely host
> page-flip.
Yes. So if we call the idea in this patch-set "in-kernel direct flip". I guess we can used the current drm ui as "out-kernel flip". It's good to see you already have the code. 

I remember you asked if gvt-g could support to deliver the page flip event to user space which could be used by qemu ui instead of using the classic qemu ui timer mechanism. If gvt-g can support it, the drm ui plus guest page flip event can be used to work as "out-kernel direct flip" I think. Can we co-work on it?

> 
> > 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.
> 
> Googling for drm leases doesn't turn up much.  Seems rarely used.
> Kernel got support.  Seems Xorg has support (or patches exist), i.e. I can ask
> the X server for a lease.
> 
> Does anything else exist?
Weston also supports it, I suppose.
https://patchwork.freedesktop.org/series/38087/

> 
> A drm lease handle can be used like a drm master handle, except that only
> the leased ressources are visible and usable, correct?
Yes. And the original owner (e.g. xorg) won't control the leased resource any more until these resource gets returned back.

So the drm ui currently can work for one guest (i.e. currently, we only can run one VM with drm ui.). However, w/ drm leasing, more than one VM seems possible.

We did some study about drm leasing. I suppose I can apply the drm leasing part to the tip of your drm ui branch. Then let's see if it's interesting.

BR,
Tina

> 
> cheers,
>   Gerd
> 
> _______________________________________________
> intel-gvt-dev mailing list
> intel-gvt-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev