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

[Gerd Hoffmann]

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?

> > 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 ...

> > > 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.

> > 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.

> 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?

cheers,
  Gerd