Hi Joonas, On Mon, Mar 07, 2016 at 12:20:48PM +0200, Joonas Lahtinen wrote: > Hi, > > On pe, 2016-03-04 at 23:38 +0800, Zhiyuan Lv wrote: > > 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! > > > > The timer best follows the "real hardware" imitation scenario, so it > should be good. Would it be an option to triple-buffer, keeping a copy > of the frame intact which the DOM0 is drawing? Or is that too harsh on > memory requirements. > > That would avoid tearing, but also let the guest freely update at > constant rate. From DOM0, the compositor or whatever application > consumes the frames, would just observe frame skipping instead of > tearing. Thanks for the idea! Keeping a copy could avoid the tearing completely. Following that approach, we may not need the special gvtbuffer gem object. We can introduce an IOCTL to copy a VM's framebuffer to a given normal gem object, then make sure that during the copy, guest driver in VM will not modify the fb. The only concern here is the performance impact, since there have to be memory copy for each frame. I do not have data in hand, but guess that might be quite significant. Thanks! Regards, -Zhiyuan > > Regards, Joonas > > > 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
