Crusty Blaa

For the past couple of weeks, I've been helping out with the Fedora 9 pv_ops effort, specifically helping get the pv_ops based dom0 kernel going.

Well, following on from sct getting dom0 booting, I made a nice breakthrough this morning - a pv_ops dom0 booting a pv_ops domU:
$> dmesg | grep paravirt Booting paravirtualized kernel on Xen $> virsh create ./test-domu.xml Domain Test created from ./test-domu.xml $> virsh console Test | grep paravirt Booting paravirtualized kernel on Xen

What's this pv_ops business all about? Well, as Dan explained, for a long time we've been forward-porting Xensource's (now 2.6.18 based) kernel tree in an effort to try and have our Xen kernel not lag behind Fedora's bare-metal kernel. Now that the upstream kernel has gained the ability to run on Xen using pv_ops (but only as i386 DomU, currently) we've taken the decision to stop wasting our time forward porting Xensource's tree and put all our focus into improving the feature set of pv_ops based Xen.

pv_ops itself is a set of hooks in the kernel so that support for running on different hypervisors can be cleanly added to the kernel, with the added bonus that the kernel can detect at runtime which hypervisor it is running on and adapt itself accordingly. This means that, in the long run, Xen support should be more akin to a device driver than a huge fork of the kernel.

(Note: for any others who ever to debug Xen's booting of a guest, here's a tiny Xen domain builder)

Just back from a nice relaxing holiday and, at first, I was totally perplexed by all this talk of the Xen "absolute pointer" problem. "It's just VNC", I thought, "it can't be that hard. It must be just a simple bug somewhere".

The background is:

• In Xen guests we have a "xenfb" driver, which acts just like a normal framebuffer device as far as the Xserver is concerned, but the contents of the framebuffer is exported to Dom0 via XenBus and shared memory.
• Similarly, we have a "xenkbd" driver, which takes input events from Dom0 and makes them available to the Xserver.
• In Dom0, we have a little daemon which acts as a VNC server. It exports the framebuffer contents from the guest and injects input events into the guest.

The problem here is that pointer motion events arrive at the Xserver as if they came directly from hardware. And just like normal mouse events, they are relative - i.e. you move your mouse up X amount and across Y amount.

This is unusual, because a VNC server receives motion events with absolute co-ordinates and can normally warp the pointer to those exact co-ordinates.

What we have might not be too bad - we might be able to reliably control the absolute pointer position in X by injecting events with relative co-ordinates - except that these events are subject to acceleration. If we try and move the pointer by injecting an event that says "move 100 pixels to the right", the Xserver may accelerate that and move it, say, 200 pixels (with a ratio of 2/1). So, Pete's first going to come up with a quick hack to disable acceleration.

It's still stupid to try and move the pointer to an absolute position by injecting relative pointer motion events, though. The ideal solution is that the pointer device in the Xen guest behaves just like a grapics tablet. We would pass the absolute pointer co-ordinates to the guest and the driver would pass those on to the Xserver as though it was tablet device.