Monthly Archives: October 2015

virtio-gpu and libvirt

libvirt has no support for virtio-vga yet. There is a bug for virtio-vga support in libvirt. But for the time being we need to play some tricks. Luckily libvirt has some special xml syntax to pass command line options to qemu. So here we go:

<domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>
  [ ... ]
  <device>
    [ ... ]
    <video>
      <model type='cirrus' vram='16384' heads='1'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
    </video>
    [ ... ]
  </devices>
  <qemu:commandline>
    <qemu:arg value='-set'/>
    <qemu:arg value='device.video0.driver=virtio-vga'/>
  </qemu:commandline>
</domain>

The idea is to tell libvirt we wanna have a cirrus vga. That one has no config options, thats why it works best for our purposes. Then use the -set switch to change the emulation driver from cirrus to virtio-vga. video0 is the id libvirt assigns to the (first and only) video device.

Next level is turning on virgl & opengl support. Initially sdl and gtk user interfaces will be supported (qemu 2.5 most likely). Spice will follow later. So lets pick gtk. Here we go:

<domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>
  [ ... ]
  <device>
    [ ... ]
    <graphics type='sdl' display=':0' xauth='/path/to/.Xauthority'/>
    <video>
      <model type='cirrus' vram='16384' heads='1'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
    </video>
    [ ... ]
  </devices>
  <qemu:commandline>
    <qemu:arg value='-set'/>
    <qemu:arg value='device.video0.driver=virtio-vga'/>
    <qemu:arg value='-display'/>
    <qemu:arg value='gtk,gl=on'/>
  </qemu:commandline>
</domain>

Simliar approach: We ask libvirt for sdl support. Picking that one because libvirt will take care to pass xauth info to qemu so it gets access to the X11 display. Then use the -display switch to override the libvirt display configuration with gtk, and turn on opengl.

One final remark: On modern linux systems xauth info is stored in /run/gdm/auth-for-$USER-$RANDOM/database instead of $HOME/.Xauthority. I have a little script to copy the xauth info to a fixed place and also make it readable so libvirt can access it:

#!/bin/sh
if test "$XAUTHORITY" != "$HOME/.Xauthority"; then
    xauth extract "$HOME/.Xauthority" "$DISPLAY"
    chmod +r $HOME/.Xauthority
fi

Note that making .Xauthority world-readable effectively gives every user on your machine access to your X11 display. On your private laptop where you are the only user that should be ok, but on a shared machine you probably want do something more secure instead.

Running Fedora on the Raspberry PI 2

The new Raspberry PI B 2 model got an armv7 core (the older ones are armv6), which makes it much easier to run Fedora on it. All Fedora packages are built for armv7, so they work as-is. Only things needed additionally are (a) the firmware and (b) a kernel. So I’ve packaged up the stuff. Firmware is just the binary stuff canned into rpms. Kernel is build from rapsberrypi git repo.

Package repository is here: https://www.kraxel.org/repos/rpi2/.
Images are here: https://www.kraxel.org/repos/rpi2/images/.

Install & usage

Just unpack the image and write it to a memory card. On first boot a rc.local script configures some things, then reboots the pi. root password is “pi”. Network is configured use dhcp on both eth0 and wlan0, using systemd-networkd. wireless needs configuration though, use wpa_passphrase "$ssid" "$psk" >> /etc/wpa_supplicant/wpa_supplicant.conf for that. kernel-rpi packages have a postinstall script updating /boot/config.txt, so kernel updates work as usual.

uboot

There is a uboot-rpi2 package as I’ve played around with u-boot. Didn’t found it that useful though. The firmware passes some command line args and a device tree to the kernel. With u-boot as boot loader inbetween that gets lost. So I’ve found myself facing problems by adding uboot to the mix, with no real advantages. Therefore the images don’t use u-boot. But you can install the rpm and play around with it if you want.

kvm

Didn’t came very far. Booting a kvm-enabled kernel in hyp mode isn’t that difficuilt. The more serve problem is that there is no GIC which kvm needs too. Someone hacked up vgic emulation to solve that issue. But the patches are old and unmaintained. They don’t rebase easily. And they also don’t solve the problem that the machine has problems accepting hardware interrupts in guest mode. Which can be worked around with isolcpus & taskset. But after all it doesn’t look like worth bothering …