Monthly Archives: April 2016

linux evdev input support in qemu 2.6

Another nice goodie coming in the qemu 2.6 release is support for linux evdev devices. qemu can pick up input events directly from the devices now, which is quite useful in case you don’t use gtk/sdl/vnc/spice for display output. Most common use case for this is vga pass-through. It’s used this way:

qemu -object input-linux,id=$name,evdev=/dev/input/event$nr

Note that udev creates symlinks with static names in /dev/input/by-id and /dev/input/by-path which you might find more convinient to use. It is possible to pass through multiple devices (i.e. mouse and keyboard).

Hitting both control keys at the same time will acquire and release the keyboard grab, i.e. it’ll switch the keyboard between guest and host. With the grab_all option enabled the keyboard hotkeys will toggle the grab for all other input devices too, so you can switch keyboard and mouse together. For the ps/2 devices on my thinkpad the command line for that looks like this:

qemu -object input-linux,id=kbd,evdev=/dev/input/by-path/platform-i8042-serio-0-event-kbd,grab_all=true
-object input-linux,id=mouse,evdev=/dev/input/by-path/platform-i8042-serio-2-event-mouse

Note: On my laptop platform-i8042-serio-1-event-mouse is the touchpad which can’t be used.

When using this with usb devices take care that they often have multiple functions, and each of them gets its own input device. The usb nano receiver for my wireless microsoft mouse has three event devices (probably because they use the same thing for all devices not only the mouse):

nilsson root ~# ls /dev/input/by-id/
usb-Microsoft_Microsoft®_Nano_Transceiver_v2.0-event-kbd
usb-Microsoft_Microsoft®_Nano_Transceiver_v2.0-if01-event-mouse
usb-Microsoft_Microsoft®_Nano_Transceiver_v2.0-if01-mouse
usb-Microsoft_Microsoft®_Nano_Transceiver_v2.0-if02-event-joystick

Enjoy!

Fedora on Raspberry PI updates

Some updates for the Running Fedora on the Raspberry PI 2 article.

There has been great progress on getting the Raspberry PI changes merged upstream in the last half year. u-boot has decent support meanwhile for the whole family, including 64bit support for the Raspberry PI 3. Raspberry PI 2 support has been merged upstream during the 4.6 merge window. It looks like Raspberry PI 3 will follow in the next (4.7) merge window. Time to have a closer look at all this new stuff.

arm images

There are two different kinds of arm images now:

First arm-rpi2-f23-foundation. They are using a kernel built from the tree maintained by the Raspberry PI Foundation at github. They are like the older ones, just with newer packages. The kernels are booted directly by the firmware.

Second arm-rpi2-f23-mainline. They are using a mainline kernel, with a few patches on top for Raspberry PI 3 support (device tree, 64bit, wifi). I expect the number of patches will decreate quickly as things get merged mainline with the next merge windows. The kernel is booted using u-boot. On the Raspberry PI 3 it’ll boot a 64bit kernel (with 32bit userspace) by default. If you don’t want that you can just run “dnf remove uboot-rpi3-64“, which will remove both 64bit uboot and kernel, then reboot.

There are no big differences between the two images types. At the end of the day it is just a different set of packages. You can move from foundation kernels (package name “kernel-rpi2” to mainline kernels (package names “kernel-main” and “kernel-main64“) and back without problems. Having them installed in parallel works fine too. The foundation kernels set kernel= in config.txt in postinstall, so one just needs to install and reboot. Switching to mainline is done by installing them, then commenting out the kernel= line in config.txt. Next boot will load uboot then, which in turn loads the mainline kernel.

arm64 images

While looking at the image directory you might have noticed the arm64-rpi3-f23-mainline image. That is a full 64bit (aka aarch64) build, with both 64bit kernel and userspace. Will boot on the Raspberry PI 3 only, for obvious reasons.

kvm

There is progress with kvm too. Recent firmware loads the kernel in hyp mode, so the hypervisor extensions are available to the linux kernel. Also it seems the kvm core and irqchip (GIC) emulation are separated now. kvm initializes successfully, but the kernel doesn’t provide irqchip because the Raspberry PI hasn’t a GIC. Result is this:

[kraxel@pi-dpy ~]$ sudo lkvm run
# lkvm run -k /boot/vmlinuz-4.5.1-103-rpi2 -m 448 -c 4 --name guest-10565
Error: Unsupported KVM extension detected: KVM_CAP_IRQCHIP
Fatal: Failed to create virtual GIC

So, userspace can’t deal with the missing GIC emulation (qemu fails too). But it looks like by doing GIC emulation in userspace it should be possible to run kvm on the Raspberry PI.

latest updates from virtio-gpu department

It’s been a while since the last virtio-cpu status report. qemu 2.6 release is just around the corner, time for a writeup about what is coming.

virgl support was added to qemu 2.5 already. It was supported only by the SDL2 and gtk UIs. Which is a nice start, but has the drawback that qemu needs direct access to your display. You can’t logout from your desktop session without also killing the virtual machine.

qemu 2.6 features headless opengl support and spice integration. qemu will use render nodes, render the guest display into dma-bufs, and pass on those dma-bufs to spice-client for display (if connected). Works for local display only for now, i.e. spice will simply display the dma-bufs. Long-term plan (after the spice video support overhaul currently in progress is merged) is to also support hardware-assisted video encoding for a remote display.

If you want play with this you need:

  • latest spice-gtk version (0.31)
  • latest spice-server development release (0.13.1)
  • virglrenderer (packages should start showing up in distros now).

If you are running fedora or rhel7 you can use my copr repo.
And of course you need latest qemu (2.6 release candidate or final release once out) too.

OpenGL support is off by default in qemu, you have to enable it manually by appending gl=on to the -spice options. libvirt 1.3.0 and newer has support for that in the domain xml. The spice client must be attached (virt-viewer –attach) using unix sockets because they are used to pass the dma-bug file descriptors.

Have fun!