[Intel-gfx] Ask for comments of getting guest framebuffer in igvt-g

Tian, Kevin kevin.tian at intel.com
Tue Mar 8 02:44:39 UTC 2016

> From: Zhiyuan Lv
> Sent: Thursday, March 03, 2016 5:51 PM
> 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!

Hi, Zhiyuan,

After reading the patchwork link, is my below understanding correct
regarding to the key logic of this new IOCTL?

- It's similar to stolen memory, i.e. the backing storage may not be
directly accessed by the driver (it's other VM's memory) so no
'page struct' is available;

- The sg_dma_address of the backing storage is retrieved directly
from GGTT entries corresponding to the gmadr of guest framebuffer,
(those entries are audited by GVT-g device model before programming 

- Then the gem object can be pinned to either GGTT or PPGTT, upon
request from user-level compositor;

- A notification will be sent by GVT-g device model, upon any change
of the guest framebuffer location,  (including change of underlying GGTT 
entry), but this notification is not implemented yet in this RFC patch;

- Upon such notification, user-level compositor is expected to destroy
previous gem object and then recreate a new object according to the
new information;

One additional comment here. Since this gem object implies another
reference to the guest memory page, we need a step to call into
GVT-g device model to claim such reference (which will then lead to a
refcnt increment of the guest page through hypervisor specific way). 
Today it's optional since our device model claims reference of all
guest memory pages in a batch at boot time, which however might
be optimized in the future to do selective claim so within device model
we need clearly mark out all explicit references. 


More information about the Intel-gfx mailing list