I've started on this long time ago, but never finished it completely. Some of the support changes were merged in 2.6 (e.g. spice-native, usb-redir, qemu upgrade and PACKAGECONFIGs), but I haven't finished the rest before 2.6 freeze, hopefully this ticket will help forcing me to finish it in 2.7 time frame. The challenge for this is that we need to build a lot of native parts in order to have a good control in what can be enabled in qemu-native with opengl enabled (without depending on host to provide compatible and usable dependencies). So we need libdrm-native, mesa-native, libepoxy-native, libjpeg-turbo-native and libsdl2-native or gtk3-native. Then there is an issues with variety of graphics cards used on host. In libdrm-native we have PACKAGECONFIGs for many, but for native build we might need to enable most of them (because we don't know what might be used on users host machine) and that brings few more dependencies. gtk3-native also pulls a lot of native dependencies, libsdl2-native is a lot easier in this aspect. My final use-case is to run qemu-native from runqemu inside docker container and connecting to it with spice client over the network or at least from outside the container. Currently virt-viewer needs to connect over unix socket for the acceleration, but exposing unix socket from docker container is more complicated than network socket. The latest state is basically the same as a year ago in: http://lists.openembedded.org/pipermail/openembedded-core/2017-September/142349.html I'm just rebasing my changes on top of current oe-core (and sometimes merge some less controversial changes to make the diff a bit smaller).
I've been working on this as well, because there's some interest in it where I work, and as an exercise to learn more about Linux graphical stack. I got the whole thing to a working proof of concept (virgl with gtk only, no spice support): http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=akanavin/virgl-gtk Some points: 0. TLDR: $ bitbake core-image-sato $ runqemu kvm gl 1. qemu is switched over to use gtk frontend. I simply couldn't get SDL frontend to work properly, it only displays a blank black window. Same thing happens with qemu binaries provided by Fedora and opensuse (Ubuntu's qemu lacks virgl support). Seems like SDL support has regressed. 2. While the components are built against the most minimum necessary mesa-native set (gbm, egl, dri with no drivers), libepoxy loads and uses the host GL implementation (through a chrpath hack). This is both to save build times, and because the host is likely to have a set of drivers more appropriate for the physical machine (e.g. proprietary nvidia stack, although I didn't test that). 3. I tested this with - glamor X server - weston compositor with drm backend (build core-image-weston, then edit weston.ini in the image to use drm backed instead of fbdev). - glxgears - https://www.geeks3d.com/gputest/ The latter two show FPS that is similar to running them directly on the host. 4. Some things I am not sure about: - how much of a 'default' should this be for running qemu. It works for me, but other people might find it less stable compared to the existing sdl-vmware-swrast setup. - what other tests and demos could be run - how could this be tested on the autobuilder I'll post this on the mailing list for discussion after the holidays.
Sadly, I have to put this on hold. I managed to get qemu to freeze the entire desktop, with two different target images, on two different physical machines. I'm not sure what is going on, but we can try this later in a few months time perhaps. Meanwhile the branch is available to anyone to pick up and carry on.
My version of the necessary changes is still in: http://git.openembedded.org/openembedded-core-contrib/log/?h=jansa/qemu the jansa/spice branch from meta-openembedded-contrib is no longer necessary, all changes are included in meta-openembedded since thud.
Right. I did not experiment with spice, only with gtk+ and sdl - and I found that neither are production quality at this moment :( virgl seems to be under active development though, hopefully it gets better.
So as my efforts to get this working all went nowhere, I tried your branch as well. I'm not sure how qemu is supposed to be executed, but I am using '-vga virtio -display sdl,gl=on' options to qemu, and the whole thing immediately crashes :( Does it work for you, is there a different way to start qemu? alexander@alexander-box:~/development/poky/build$ LIBGL_DRIVERS_PATH=tmp/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/lib/dri/ runqemu kvm runqemu - INFO - Running bitbake -e... runqemu - INFO - Continuing with the following parameters: KERNEL: [/home/alexander/development/poky/build/tmp/deploy/images/qemux86/bzImage--4.18.21+git0+8f4a98c938_9eddc793f9-r0-qemux86-20190111112857.bin] MACHINE: [qemux86] FSTYPE: [ext4] ROOTFS: [/home/alexander/development/poky/build/tmp/deploy/images/qemux86/core-image-minimal-qemux86-20190111112857.rootfs.ext4] CONFFILE: [/home/alexander/development/poky/build/tmp/deploy/images/qemux86/core-image-minimal-qemux86-20190111112857.qemuboot.conf] runqemu - INFO - Setting up tap interface under sudo runqemu - INFO - Network configuration: 192.168.7.2::192.168.7.1:255.255.255.0 runqemu - INFO - Running /home/alexander/development/poky/build/tmp/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/bin/qemu-system-i386 -device virtio-net-pci,netdev=net0,mac=52:54:00:12:34:02 -netdev tap,id=net0,ifname=tap0,script=no,downscript=no -drive file=/home/alexander/development/poky/build/tmp/deploy/images/qemux86/core-image-minimal-qemux86-20190111112857.rootfs.ext4,if=virtio,format=raw -vga virtio -display sdl,gl=on -show-cursor -usb -device usb-tablet -object rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-pci,rng=rng0 -cpu pentium2 -enable-kvm -m 256 -serial mon:vc -serial null -kernel /home/alexander/development/poky/build/tmp/deploy/images/qemux86/bzImage--4.18.21+git0+8f4a98c938_9eddc793f9-r0-qemux86-20190111112857.bin -append 'root=/dev/vda rw highres=off clocksource=kvm-clock hpet=disable noapic nolapic mem=256M ip=192.168.7.2::192.168.7.1:255.255.255.0 vga=0 uvesafb.mode_option=640x480-32 oprofile.timer=1 uvesafb.task_timeout=-1 ' runqemu - ERROR - Failed to run qemu: runqemu - INFO - Cleaning up Set 'tap0' nonpersistent
I found the cause of troubles with gtk+, and the whole thing seems to run stable now. I'll polish up the patchset and add some tests, then seek feedback on oe-core list.
Somehow with the latest components also SDL now works fine for me. I have posted the patchset once more: http://lists.openembedded.org/pipermail/openembedded-core/2019-September/286433.html so please test and maybe show support on the list - let's try to get this merged.
I have finally got all of my patches merged for this, so the remaining bits are usb-redir and spice support. If you are still interested to work on these, the bug is yours now. For all three options (gtk, sdl, headless) runqemu redirects native mesa to use dri drivers from the host; there are occasional incompatibilities (when the host distro is 'too old'), but otherwise it works ok. The alternative is building the drivers ourselves, and that would likely never be accepted as the default setting due to build times impact.
spice and usbredir works fine for quite some time, PACKAGECONFIG for them was added in: commit ebb6ef1dbc7e03a4b7030b3056bd0fa59fdd047b Author: Martin Jansa <martin.jansa@gmail.com> Date: Fri Jun 1 10:29:40 2018 +0000 qemu: add PACKAGECONFIG for virglrenderer, usb-redir and spice and the recipes were added to meta-networking shortly after that. Thanks Alex for finishing and cleaning the oe-core bits! Closing as fixed.