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

Gerd Hoffmann kraxel at redhat.com
Thu May 23 10:49:48 UTC 2019


  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?

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

> And the "topic/drm-ui-direct-flip" branch is tracking drm ui branch.

Cool, thanks, I'll play with that.

cheers,
  Gerd



More information about the intel-gvt-dev mailing list