Two new images uploaded

Uploded two new images.

First a centos7 image for the raspberry pi 3 (arm64). Very simliar to the fedora images, see the other raspberrypi posts for details.

Second a armv7 qemu image with grub2 boot loader. Boots with efi firmware (edk2/tianocore). No need to copy kernel+initrd from the image and pass that to qemu, making the boot process much more convenient. Looks like this will not land in Fedora though. The Fedora maintainers prefer to stick with u-boot for armv7 and plan to impove u-boot instead so it works better with qemu. Which will of course solve the boot issue too, but it doesn’t exist today.

Usage: Fetch edk2.git-arm from the firmware repo. Use this to define a libvirt guest:

<domain type='qemu'>
  <name>fedora-armv7</name>
  <memory unit='KiB'>1048576</memory>
  <os>
    <type arch='armv7l' machine='virt'>hvm</type>
    <loader readonly='yes' type='pflash'>/usr/share/edk2.git/arm/QEMU_EFI-pflash.raw</loader>
    <nvram template='/usr/share/edk2.git/arm/vars-template-pflash.raw'/>
  </os>
  <features>
    <gic version='2'/>
  </features>
  <cpu mode='custom' match='exact'>
    <model fallback='allow'>cortex-a15</model>
  </cpu>
  <devices>
    <disk type='file' device='disk'>
      <driver name='qemu' type='raw'/>
      <source file='/path/to/arm-qemu-f24-uefi.raw'/>
      <target dev='sda' bus='scsi'/>
      <boot order='1'/>
      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
    </disk>
    <controller type='pci' index='0' model='pcie-root'/>
    <controller type='scsi' index='0' model='virtio-scsi'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/>
    </controller>
    <console/>
  </devices>
</domain>

Update 1: root password for the qemu uefi image is “uefi”.
Update 2: comments closed due to spam flood, sorry.

New Raspberry PI images uploaded.

I’ve uploaded new images. Both a Fedora 23 refresh and new Fedora 24 images. There are not many changes, almost all notes from the two older articles here and here still apply.

Noteworthy change is that the 32bit images don’t have a 64bit kernel for the rpi3 any more, so both rpi2 and rpi3 boot a armv7 kernel. If you want run your rpi3 in 64bit mode go for the arm64 image which has both 64bit kernel and userspace. Reason for that is that 32bit dnf running on a 64bit kernel throws errors due to the unknown aarch64 architecture so you can’t update the system. And, no, using “linux32 dnf …” doesn’t work either, dnf still complains, it doesn’t know what armv8 is …

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!

fbida 2.11 released

New fbida release is out.

Needed something lightweight for drm testing. So I’ve decided to give the fbi display code a overhaul:

  • Untangled the console switching code from the fbdev code.
  • Added support for drm, which also is the new default.
  • Missing console switching support is not a fatal error any more.

The last item implies that you can start fbi from a remote login just fine now. When running on drm this actually works pretty well, fbi will simply allocate a new framebuffer and link it to the output, so things are nicely separated. When running on fbdev framebuffer access coordination goes away without console switching, so fbi and other users can draw at the same time. So if you find a friendly blinking fbcon cursor in the middle if your image, this is the reason for it.

Download the bits here.

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 …

New member in the virtio family: input devices.

overview

If you have build a fresh 4.1-rc kernel you might have already noticed the new CONFIG_VIRTIO_INPUT config option. So, here is some background information on what this is and how to use it.

virtio-input basically sends linux evdev events over virtio. The device capability bits (available via ioctl for evdev) live in virtio device config space. The events themself are sent over virtio queues. They look exactly like evdev events, except that the struct fields are always in little endian byte order. So this allows the host to emulate pretty much any input device the linux kernel’s input layer is able to handle.

On the guest side the only thing you need is a kernel with CONFIG_VIRTIO_INPUT=m.

On the host side you need pretty recent qemu master branch. The first release with virtio-input support will be 2.4.

emulated devices

qemu has three virtual devices right now:

  • -device virtio-keyboard-pci : virtual keyboard, simliar to the ps/2 keyboard.
  • -device virtio-mouse-pci : virtual mouse, simliar to the ps/2 mouse.
  • -device virtio-tablet-pci : virtual tablet, simliar to usb-tablet, but without the usb overhead.

The tablet is probably the most useful one in practice. The pseries guys might be interested in the keyboard too as usb-keyboard replacement.

device pass-though

Not yet merged, but the patch should land upstream in time for the 2.4 release: There also is support for passing through host evdev devices to the guest:

-device virtio-input-host-pci,evdev=/dev/input/eventn

Take care: The guest gets exclusive access to the input device then. So better don’t try that with your one and only keyboard 😉