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 …
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-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
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/
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 …
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.
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.
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:
Take care: The guest gets exclusive access to the input device then. So better don’t try that with your one and only keyboard 😉
We are making progress, time for the next status report …
virtio-gpu, 2d mode
It’s on the way upstream, both guest and host side. The qemu code landed in git master already and will be shipped with the upcoming 2.4 release. The linux kms driver is in drm-next right now and will most likely land upstream in the 4.2 merge window.
virtio-gpu, 3d mode
With 2d mode being almost completed now the focus shifts to put 3d/virgl into shape.
The qemu code is in a new virgl branch now, the vga and ui bits are no longer separated.
Current state: SDL2 display is working. egl display (headless, see below) is working.
TODO list: Make gtk diplay (egl mode) work. Add support for native opengl (available in 3.16+, needed to run on wayland) to gtk display. Add spice support.
Building qemu with virgl:
You need virglrenderer. Copr has packages. If you want try egl display too you need pretty cutting edge mesa and libepoxy packages, for dma-buf export and import support. Fedora 22 will do for mesa. For libepoxy you need the rawhide/F23 version.
Linux guest bits for virgl:
The virtio-gpu branch in my linux repo has the kernel bits you need. The Copr repos have a “mesa.git” package which you need to install. This isn’t full mesa, only the guest driver for virtio-gpu. I suggest to use Fedora 22 as guest as I’m usually testing with F22 too.
You might need to put selinux (at the host) into permissive mode when playing with this. svirt doesn’t allow qemu access the gpu.
headless egl display
In this mode qemu doesn’t need access to your X11 (or wayland) display. It’ll open a drm render node instead and use that for opengl operations. The guest display is rendered into a dma-buf. A simple standalone app can connect to qemu, get access to the dma-bufs via file descriptor passing and blit the dma-buf to your screen.
qemu-system-x86_64 -display egl -name $name
The viewer is proof-of-concept for the dma-buf passing and it is pretty simple. No pointer shape support. No relative pointer support, so a tablet device is mandatory for the guest if you want a working pointer.
Not sure yet how the long-term future will look like for qemu-eglview. Right now it is a useful hacking and testing tool. But spice will some day operate in a very simliar way and additionally provide all the extra goodies spice has to offer (sound, usb, smartcard, webdav, …), so it probably isn’t that useful to turn it into a full-blown viewer app …