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

Thu May 23 09:20:17 UTC 2019

> -----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 4:50 PM
> To: Zhang, Tina <tina.zhang at intel.com>
> Cc: Tian, Kevin <kevin.tian at intel.com>; Wang, Zhi A
> <zhi.a.wang at intel.com>; zhenyuw at linux.intel.com; Yuan, Hang
> <hang.yuan at 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; ville.syrjala at linux.intel.com
> Subject: Re: [RFC PATCH v2 0/3] drm/i915/gvt: Enable vGPU local display
> direct flip
> 
> On Wed, May 22, 2019 at 06:33:18AM +0000, Zhang, Tina wrote:
> 
> > > > 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.
> >
> > 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.
> 
> 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. 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.

> 
> > > Can userspace mmap() the dmabuf?
> > No.
> >
> > > Can userspace import the dmabuf as egl image, then use it as texture
> > > or framebuffer?
> > No.
> 
> Hmm, that somehow contradicts the claim above that userspace can use the
> dmabuf interface in traditional mode even with the switch enabled ...
Sorry about the confusion. The drm_framebuffer used by gvt-g in kernel to do the page flip won't be exported to the user space. Its life cycle is handled by gvt-g.

> 
> > > > 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 :-)
> 
> > 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?
> 
> Sure.  I think a vfio ioctl which returns an eventfd for page-flip notifications
> should work nicely.
Agree.

> 
> > > 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/
> 
> For logind it would make sense too, it could hand out drm lease handles
> instead of drm master handles and allow multiple display servers running in
> parallel that way.
> 
> Seems that didn't happen yet though.
> 
> > > A drm lease handle can be used like a drm master handle, except that
> > > only the leased ressources are visible and usable, correct?
> 
> > 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.
> 
> 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.

> 
> > 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.
> 
> Can you just push your drm lease branch somewhere?
I applied our work against your drm ui tip. You can run it with xorg now. We tried two VMs with two display monitors and it can work just as expected.
BTW, you might need to update some packages to the latest version, e.g. xorg, in order to use the drm lease. If you have any problem, please let me know.
Here is the commit: https://github.com/intel/Igvtg-qemu/commit/2881d9a65beb319c42b947d23eb1d260224bcddc
And the "topic/drm-ui-direct-flip" branch is tracking drm ui branch.

Thanks.

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