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

[Joonas Lahtinen]

Hi,

On to, 2016-03-03 at 17:50 +0800, Zhiyuan Lv wrote:
> 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.
> 

Could you elborate here? I guess the idea is to make the guest think it
is operating with regular hardware. So I think the owner of a gvtbuffer
will inject the vblank when it has consumed the current framebuffer
data, pretty much like with real hardware. Or what else would trigger
vblank?

Otherwise tearing can not be avoided. Or will the guest be more aware
of being under graphics virtualization than that?

Regards, Joonas

> 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
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation