<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv="Content-Type" content="text/html; charset=us-ascii"> <meta name="Generator" content="Microsoft Word 15 (filtered medium)"> <style></style> </head> <body lang="EN-US" link="#0563C1" vlink="#954F72"> <div class="WordSection1"> Hi,<o:p></o:p> <o:p> </o:p> We’re working on enabling a new feature called “Local Display Direct Flip” in GVT-g. And we want to use this thread to introduce this feature and discuss the userspace interface.<o:p></o:p> <o:p> </o:p> What is the local display direct flip feature?<o:p></o:p> This feature provides vGPUs with the capabilities to control a subset of the local HW display engine resources to display output from a virtualized environment. With this feature, vGPUs can leverage HW display engine's capabilities to compose their framebuffers and post the final outputs to the assigned local display monitors.<o:p></o:p> Please see <a href="https://lists.freedesktop.org/archives/intel-gvt-dev/2018-December/004559.html"> https://lists.freedesktop.org/archives/intel-gvt-dev/2018-December/004559.html</a> for details.<o:p></o:p> <o:p> </o:p> Why the proposed local display direct flip feature is considered more efficient?<o:p></o:p> Currently, GVT-g upstream support local display based on dma-buf. For example, with dma-buf, GTK UI can compose the guest framebuffers and post the final framebuffer to the local display monitor. Although this dma-buf solution is flexible for both local display and remote display, this solution has to involve userspace when the guest framebuffer is updated. And usually, this happens every frame.<o:p></o:p> <o:p> </o:p> Meanwhile, local display direct flip feature doesn’t need to involve userspace for the guest plane update. Userspace just needs to do the assignment once (although the feature supports the dynamic assignment), and planes on the assigned pipe can be leveraged by the guest to compose its framebuffers w/o involving host userspace any more. That’s why it’s considered more efficient.<o:p></o:p> <o:p> </o:p> The proposed userspace interface:<o:p></o:p> Each plane of the vGPU is exposed as a DRM framebuffer object in the host-side during the vGPU creation. So host userspace can assign the HW display planes to vGPU’s planes by using existing DRM/KMS APIs. After the assignment, host kernel can directly help guest to update the information to the display registers of the assigned display resources. However, the only problem is how we return the DRM framebuffer id to host userspace.<o:p></o:p> <o:p> </o:p> Currently, we have two options:<o:p></o:p> <![if !supportLists]>1. <![endif]>Through “/sys/bus/pci/devices/0000:00:02.0/$UUID/intel_vgpu/plane_id_index”<o:p></o:p> <pre style="margin-left:.5in">With the proposed “plane_id_index” attribute, userspace can echo the plane number to the attribute and then use cat to dump the userspace id of the DRM framebuffer standing for that vGPU’s plane in the host-side.<o:p></o:p></pre> <![if !supportLists]>2. <![endif]>Through vfio ioctl:<o:p></o:p> We can extend VFIO_DEVICE_QUERY_GFX_PLANE ABI by proposing “VFIO_GFX_PLANE_TYPE_DRM_FB” type. So that vendor driver can return the framebuffer id when userspace invoking “VFIO_DEVICE_QUERY_GFX_PLANE” ioctl with flags as “VFIO_GFX_PLANE_TYPE_DRM_FB | VFIO_GFX_PLANE_TYPE_PROBE”<o:p></o:p> <o:p> </o:p> The patches are on:<o:p></o:p> <a href="https://github.com/intel/igvtg-qemu/tree/topic/local_display_direct_flip">https://github.com/intel/igvtg-qemu/tree/topic/local_display_direct_flip</a><o:p></o:p> <a href="https://github.com/intel/gvt-linux/tree/topic/local_display_direct_flip">https://github.com/intel/gvt-linux/tree/topic/local_display_direct_flip</a><o:p></o:p> <o:p> </o:p> How to try it:<o:p></o:p> Qemu: <a href="https://github.com/intel/igvtg-qemu/tree/topic/local_display_direct_flip"> https://github.com/intel/igvtg-qemu/tree/topic/local_display_direct_flip</a><o:p></o:p> Kernel: <a href="https://github.com/intel/gvt-linux/tree/topic/local_display_direct_flip"> https://github.com/intel/gvt-linux/tree/topic/local_display_direct_flip</a><o:p></o:p> (Note: these branches include both of the two options of userspace interface and they are live branches as WIP)<o:p></o:p> <o:p> </o:p> The reference boot script:<o:p></o:p> -m 4096 -smp 2 -M pc \<o:p></o:p> -name kvmgt1 \<o:p></o:p> -hda $1 \<o:p></o:p> -bios /home/tinazhang/workspace/KVMGT/qemu-upstream/qemu/roms/seabios/out/bios.bin -enable-kvm \<o:p></o:p> -net nic,macaddr=00:A1:00:00:00:BD -net tap,script=/etc/qemu-ifup \<o:p></o:p> -vga none \<o:p></o:p> -display kms \<o:p></o:p> -k en-us \<o:p></o:p> -serial stdio \<o:p></o:p> -machine kernel_irqchip=on \<o:p></o:p> -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 \<o:p></o:p> -cpu host -usb -usbdevice tablet \<o:p></o:p> -device vfio-pci,sysfsdev=/sys/bus/pci/devices/0000:00:02.0/$UUID,rombar=0,x-igd-opregion=on,display=on<o:p></o:p> <o:p> </o:p> To-do list:<o:p></o:p> We got kernel-side to-do list here: <a href="https://lists.freedesktop.org/archives/intel-gvt-dev/2018-December/004559.html"> https://lists.freedesktop.org/archives/intel-gvt-dev/2018-December/004559.html</a><o:p></o:p> <o:p> </o:p> Besides, here is one for the proposed Qemu KMS UI and hope that one could be interesting.<o:p></o:p> To support Mult-VMs pipe assignment by assigning each crtc to a VM:<o:p></o:p> The proposed KMS UI can only support one VM pipe assignment, due to the DRM master limitation. However, kernel has supported a feature called DRM-lease (<a href="https://keithp.com/blogs/DRM-lease-2/">https://keithp.com/blogs/DRM-lease-2/</a>). And userspace graphics stacks have also implemented this feature. This can solve the DRM master problem by leasing the pipe and its resources to one App which is Qemu in our case.<o:p></o:p> <o:p> </o:p> Thanks.<o:p></o:p> <o:p> </o:p> <o:p> </o:p> <o:p> </o:p> BR,<o:p></o:p> Tina<o:p></o:p> <o:p> </o:p> <o:p> </o:p> <o:p> </o:p> <o:p> </o:p> </div> </body> </html>