On Thu, Nov 19, 2015 at 01:02:36PM -0700, Alex Williamson wrote: > On Thu, 2015-11-19 at 04:06 +0000, Tian, Kevin wrote: > > > From: Alex Williamson [mailto:alex.williamson@xxxxxxxxxx] > > > Sent: Thursday, November 19, 2015 2:12 AM > > > > > > [cc +qemu-devel, +paolo, +gerd] > > > > > > Another area of extension is how to expose a framebuffer to QEMU for > > > seamless integration into a SPICE/VNC channel. For this I believe we > > > could use a new region, much like we've done to expose VGA access > > > through a vfio device file descriptor. An area within this new > > > framebuffer region could be directly mappable in QEMU while a > > > non-mappable page, at a standard location with standardized format, > > > provides a description of framebuffer and potentially even a > > > communication channel to synchronize framebuffer captures. This would > > > be new code for QEMU, but something we could share among all vGPU > > > implementations. > > > > Now GVT-g already provides an interface to decode framebuffer information, > > w/ an assumption that the framebuffer will be further composited into > > OpenGL APIs. So the format is defined according to OpenGL definition. > > Does that meet SPICE requirement? > > > > Another thing to be added. Framebuffers are frequently switched in > > reality. So either Qemu needs to poll or a notification mechanism is required. > > And since it's dynamic, having framebuffer page directly exposed in the > > new region might be tricky. We can just expose framebuffer information > > (including base, format, etc.) and let Qemu to map separately out of VFIO > > interface. > > Sure, we'll need to work out that interface, but it's also possible that > the framebuffer region is simply remapped to another area of the device > (ie. multiple interfaces mapping the same thing) by the vfio device > driver. Whether it's easier to do that or make the framebuffer region > reference another region is something we'll need to see. > > > And... this works fine with vGPU model since software knows all the > > detail about framebuffer. However in pass-through case, who do you expect > > to provide that information? Is it OK to introduce vGPU specific APIs in > > VFIO? > > Yes, vGPU may have additional features, like a framebuffer area, that > aren't present or optional for direct assignment. Obviously we support > direct assignment of GPUs for some vendors already without this feature. For exposing framebuffers for spice/vnc I highly recommend against anything that looks like a bar/fixed mmio range mapping. First this means the kernel driver needs to internally fake remapping, which isn't fun. Second we can't get at the memory in an easy fashion for hw-accelerated compositing. My recoomendation is to build the actual memory access for underlying framebuffers on top of dma-buf, so that it can be vacuumed up by e.g. the host gpu driver again for rendering. For userspace the generic part would simply be an invalidate-fb signal, with the new dma-buf supplied. Upsides: - You can composit stuff with the gpu. - VRAM and other kinds of resources (even stuff not visible in pci bars) can be represented. Downside: Tracking mapping changes on the guest side won't be any easier. This is mostly a problem for integrated gpus, since discrete ones usually require contiguous vram for scanout. I think saying "don't do that" is a valid option though, i.e. we're assuming that page mappings for a in-use scanout range never changes on the guest side. That is true for at least all the current linux drivers. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
