Ask for comments of getting guest framebuffer in igvt-g

From: Zhiyuan Lv <zhiyuan.lv@intel.com>
To: joonas.lahtinen@linux.intel.com, daniel.vetter@ffwll.ch,
	chris@chris-wilson.co.uk, david.j.cowperthwaite@intel.com
Cc: intel-gfx@lists.freedesktop.org, igvt-g@lists.01.org
Subject: Ask for comments of getting guest framebuffer in igvt-g
Date: Thu, 3 Mar 2016 17:50:42 +0800	[thread overview]
Message-ID: <20160303095042.GA9093@zlv-hp-dev> (raw)

Dear i915 developers,

Here I have one topic hoping to get your comments and suggestions.
Basically it is about graphics virtualization(igvt-g), for the purpose
of host system to get virtual machine's framebuffer. We would like to
hear your opinions about some design opens. Below is the
patch and some more detailed description. We appreciate your time
on that, and thanks in advance for any comments!

https://patchwork.freedesktop.org/patch/71852/

When people try igvt-g, one common question we heard is how to get
guest VM's framebuffer. It is for various purposes:

 - A compositor in host (it can be QEMU itself or other viewer
   applications) can use the contents to render a window in host;

 - Remote protocol can easily handle it to support 3D/Media
   accelerated VMs;

The specific requirements include:

 - Be able to map the guest framebuffer so that host CPU can read it;
 - Be able to export guest framebuffer through dam_buf;
 - Be able to direct render with guest framebuffers;

In order to support that, we introduced a new gem object called
gvtbuffer. It is a special object with guest framebuffer's pages as
its backing storage. Meanwhile, it could behave normally like other
gem objects. It can be mapped, exported and used by EGL APIs.

Although we say guest fb pages for gvtbuffer, the solution itself is
safe. Because gvtbuffer gets entries from physical GGTT which cannot
be accessed by guest VM directly. igvt-g device model is responsible
for filling physical GGTT after translating the iova from guest GGTT
table. Even if a malicious guest uses a bad framebuffer, the pages
filled in GGTT are always valid. Then when gvtbuffer tries to get some
entries, they are always valid address not causing hardware problems.

It is possible, however, that the guest VM performs page flip while
gvtbuffer is attached with the framebuffer, and is being used for
rendering. That may cause some tearing in theory. But in practice, we
did not see that. If that is a concern, we can consider to delay the
VBLANK irq injection to guest as a solution.

So in general, do you think it is OK to introduce the gvtbuffer gem
object, or there could be better way to handle it in gem framework?

Currently we have a new IOCTL added for the gvtbuffer, and we also
added some data structures to describe the framebuffer format for user
mode. Do you think that is fine? Thanks again!

Regards,
-Zhiyuan
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx