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

[Zhiyuan Lv]

Hi Joonas,

On Fri, Mar 04, 2016 at 04:00:27PM +0200, Joonas Lahtinen wrote:
> 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?

The igvt device model is responsible for injecting vblank interrupts to VMs
for i915 running inside. Currently we have a timer for the regular vblank
injection. So if needed, host i915 can notify gvt device model to delay
vblank for a VM, hence delay the flip from VM's point of view. BTW, the idea
of delay is not in current gvt code. We are not sure whether it is a must to
have and whether it is the best way. Just feel that it is doable. Thanks!

Regards,
-Zhiyuan

> 
> 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
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx