Category Archives: Uncategorized

local vgpu display – status update

After a looong time things are finally landing upstream. Both vfio API update for vgpu local display support and support for that in the intel drm driver have been merged during the 4.16 merge window. Should not take too long to get the qemu changes merged upstream now, if all goes well the next release (2.12) will have it.

Tina Zhang wrote a nice blog article with both technical background and instructions for those who want play with it.

local display for intel vgpu starts working

Intel vgpu guest display shows up in the qemu gtk window. This is a linux kernel booted to the dracut emergency shell prompt, with the framebuffer console running @ inteldrmfb. Booting a full linux guest with X11 and/or wayland not tested yet. There are rendering glitches too, running “dmesg” looks like this:

So, a bunch of issues to solve before this is ready for users, but it’s a nice start.

For the brave:

host kernel:

Take care, both branches are moving targets (aka: rebasing at times).

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/


IPv6 is taking off

I’m running a IPv6-enabled network, for a few years already. Internet connectivity goes through a SixXS tunnel. DNS services are provided by a bind instance. The machines on the local network have both IPv4 and IPv6 DNS entries there. Bind does also act as DNS cache, and of course it is reachable with both IPv4 and IPv6. dhcpd hands out IPv4 addresses to everybody, radvd does the same for IPv6, both point to to the bind instance for DNS service.

Recently I’ve purchased a cubietruck so I can play around with arm virtualization. Installed & configured the box, created fedora arm guests. Logged in, updated the virtual machines (loading updates from the fedora mirror network), all worked just fine. Then, after a few days, I’ve figured that dhcp was not turned on in the guests. They ran without IPv4 connectivity, and I didn’t even notice!

Simliar thing happened with my jenkins build host. It somehow lost IPv4 connectivity. Not fully sure why, but there was a power failure and the dhcp server wasn’t available for a while, guess this was the reason. Nevertheless almost everything continued to work just fine. Jenkins performed builds, I could see the results in the web gui. What didn’t work was pulling github repos, because github can’t be reached using IPv6. Needless to say this took me a few days too to figure.

Is amazing how well things are working meanwhile with IPv6 only.

colorful crash

Most of the time the crashes are boring, the machine just hangs or reboots. This one is different 😉

Looks like someone dumps random crap into the vga text mode memory, root cause not figured yet.