Just received a email asking where we are in terms of virgl support in qemu, partly because the links from last years kvm talk are outdated meanwhile. I suspect there might be more folks wondering, so it is probably a good idea to write up an update in public. So, here we go with the news …
virglrenderer isn’t a branch in Dave’s mesa repo any more, it got factored out into its own git repo.
The mesa guest driver still is in Dave’s mesa repo (branch virgl-mesa-driver).
The xorg guest driver is not needed any more because xorg can do 2d acceleration via opengl/mesa now.
The guest kernel driver is in my virtio-gpu branch.
The qemu bits are splitted over two branches at the moment: The sdl2 and opengl bits are in my sdl branch, whereas the virtio-gpu bits are in the vga branch. In theory making things work should be as easy as merging these two branches. I didn’t test this for a while though as I’m busy bringing the first batch of virtio-gpu patches (with 2d support only) into shape for upstream merging.
Upstream merge is stalled atm because the virtio-gpu patches depend on virtio 1.0 support, which in turn is blocked by qemu being in freeze for the 2.3 release right now. Things should start moving forward very soon though, once qemu 2.3 is released the master branch will be opened for 2.4 development.
New fbida release is out. Nothing earth shaking, just a bunch of small fixes piled up over time. Now bundled as new release tarball. Download the bits here.
Cirrus is a hardware design from the 90ies and simply can’t keep up with todays needs.
- Want a Full HD display? No way with cirrus.
- See funky glitches in your X11 display? Yep, that’s because cirrus uses 24 instead of 32 bits per pixel for truecolor. Modern video hardware stopped doing at least a decade ago, so these code paths in Xorg are largely unused and do bitrot.
And because the cirrus emulation must mimic the behaviour of the real hardware there is no way to fix this in qemu. For historic and compatibility reasons cirrus is the default vga in qemu, but luckily there are other choices.
Cirrus may have its valid use cases with guests which are from the 90ies too, such as Windows NT4. With modern guests you are much better off using stdvga (
-vga std) or qxl (
-vga qxl) instead.
If you are using spice the best choice is qxl. Install guest drivers for best performance, without guest drivers qxl offers no benefits over stdvga. Linux distros should have the qxl driver packaged up and possibly even installed by default, so that is easy. Windows drivers are here.
stdvga on linux: In version 3.14 the kernel finally got a kms driver for the qemu stdvga. If you have that: Make sure CONFIG_DRM_BOCHS is enabled (most likely your distro did that already for you), be happy. Xorg runs the stdvga with the modesetting driver.
xrandr works as it should. If you are not happy with the predefined list of modes just add your own via
xrandr --newmode or
xorg.conf. If highres modes don’t work use more video memory:
qemu -vga std -global VGA.vgamem_mb=32 doubles the default size.
With older linux kernels Xorg will use the vesa driver for stdvga. It is less comfortable to use than modesetting. You are limited to the modes exposed by vgabios, but you still get more modes than with cirrus. You have to create a xorg.conf snippet with monitor refresh rates to convince Xorg that it can use higher resolution without blowing the virtual monitor. Nevertheless it is still the easy way out if you suffer cirrus display glitches.
stdvga on windows: Windows XP (which just went out of support) is the last windows release shipping with cirrus drivers. With anything more recent there is zero benefit in preferring cirrus over stdvga. In both cases windows uses the vgabios (VBE 2.0) for modeswitching and a simple framebuffer without any acceleration support. But stdvga has more video memory and allows higher display resolutions.
Gave a talk about graphics on qemu at KVM Forum yesterday.
For those which where not able to attend: The slides are here.
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.
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.
This server has been reachable via https for quite some time already. Starting today any unencrypted http request will be redirected to the encrypted https page, effectively forcing encrypted connections.
Next release for the input utility collection. A bunch of fixes piled up in git over the last years. High time to do a release.
Also lsinput got a overhaul, by default it prints a compact, one line per device format now. Got switches for a verbose listing (-v) and to limit output to a specific device (-s), simliar to lspci and lsusb. Long overdue with lots of stuff using the input layer these days, my laptop has 20 evdev devices …
It’s a long standing problem that the qemu cpu consumtion goes up when you hook up a usb-tablet to your virtual machine to get a absolute pointing device. The underlying problem is that the usb host adapter by design polls the usb devices. The hardware design of the uhci, ohci and ehci usb host adapters pretty much forces qemu to do the same polling when emulating the host adapter, which is where the cpu consumption comes from.
There are a few ways to tackle the problem.
Number one is using the xhci host adapter emulation. xhci has a radically different hardware design, which allows to emulate it with noticeable less cpu overhead compared to uhci and ehci. Unfortunately only win8+ ships with xhci support, so that doesn’t fly for older windows versions.
Number two is remote wakeup. When usb devices support remote wakeup the usb host adapter can suspend the usb device (i.e. stop polling for events). The usb device will signal a wakeup request when it has new events to deliver and wants the usb host adapter resume polling to deliver the new events. The purpose of this mechanism is to save power. It also reduces the cpu consumption of the usb emulation in qemu. Unfortunately remote wakeup support often is broken in usb devices (that includes usb hid device emulation in qemu up to version 0.12), and operating systems do not enable remote wakeup by default because of that.
For linux guests the problem is long solved. udev got some rules (see 42-usb-hid-pm.rules) to enable remote wakeup for the usb hid devices emulated by qemu a few years ago, so on any recent linux distro the usb tablet will be suspended when idle.
For windows guests the
upcoming qemu 2.0 release has improvements, qemu got support for Microsoft OS Descriptors. They can be used to turn on remote wakeup by default on windows guests. There are a few obstacles through. First is that it is turned of for compatibility reasons on older machine types, so make sure you are using a 2.0 machine type (pc-i440fx-2.0 or pc-q35-2.0), otherwise you don’t get this. Second is that windows checks for Microsoft OS Descriptors only once, then caches the result in the registry. Therefore existing windows guest image will not notice without manual invention. Deleting these two registry subtrees …
… and rebooting should do the trick. Windows will re-detect the usb devices and should enable remote wakeup support for the usb-tablet. You can verify this using the device manager:
If the “Power Management” tab is present and “Allow the computer to turn off this device to save power” is checked everything is fine.
Update: qemu 2.0 has been released on April 17th, 2014.
The input utility collection gets it first formal release. Yay. You can stop using the cvs snapshots now.