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