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