September
Sub-archives
Xen update
I found a machine which is not so ancient and did some tests with Xen on it.
Kernels
First was some tests with different Linux kernels and hypervisors (3.2 and 3.3). I have to say the overall compatibility got better. As unpriviledged domain (DomU) only one of the kernels failed, the one from Etch (2.6.18-6-xen-686) on the x86_64 hypervisor because of missing setup code.
For the operation as priviledged domain (Dom0) it looks not so good. The 2.6.18 from Xen 3.1 works mostly, the Lenny-targeted 2.6.26 is a little bit picky about the hardware and seems to work better in the 64bit variant, the 2.6.18 from 3.3 is old but rock-stable.
Stub domain
Xen 3.3 adds the possibility to move a the qemu which provides the emulated hardware for full virtualized domains in its own (paravirtualized) domain. The documentation is not really complete and the whole thing rather fragile. Error messages from the emulation domain are swallowed and depending on the config it also likes to crash.
It wants a new service, a filesystem backend, which is implemented in a root process in the dom0, even if it is not needed for operation. This service is not configurable, exports anything in /exports and allows writing, the code have similar quality then qemu.
Smallest UTF32 to UTF8 converter
I found some weird opcodes in the s390 instruction set some time ago. I finally want to use it as I have access to such a machine. The result is rather slim:
.globl cu41
.type cu41, @function
cu41:
.L2:
cu41 %r2,%r4
ipm %r1
srl %r1,28
chi %r1,3
je .L2
ltr %r1,%r1
je .L3
lcr %r1,%r1
lgfr %r3,%r1
.L3:
lgr %r2,%r3
br %r14
The cu41 opcode translates UTF32 to UTF8. Each "parameter" is a register pair [1], which describes address and length of the buffer. This opcode will return after a not specified number of translated characters. The rest is boiler plate code for condition code checking. The loop makes sure that anything is converted within the function unless another error occured.
| [1] | An even pair. gcc is not yet able to allocate such pairs on its own, so it is hardcoded. |
PV-GRUB and partitions
Xen 3.3 added a tool called PV-GRUB. It is a GRUB (legacy aka 0.97) built against MiniOS and bootable as a PV kernel. It works fine on a Xen 3.2.1.
It is easy to use, I just set this in my config:
kernel = "/usr/local/lib/xen/boot/pv-grub-x86_64.gz" extra = "(hd0)/boot/grub/menu.lst"
However it decided to not load my config as defined in the config and simply show me that:
GNU GRUB version 0.97 (524288K lower / 0K upper memory)
[ Minimal BASH-like line editing is supported. For
the first word, TAB lists possible command
completions. Anywhere else TAB lists the possible
completions of a device/filename. ]
grubdom>
The reason is quite easy:
grubdom> root (hd0) Filesystem type unknown, using whole disk
Some debugging later, the reason is known and fixed.
grubdom> root (hd0) Filesystem type is ext2fs, using whole disk grubdom> kernel /boot/vmlinuz-2.6.27-rc5-amd64 grubdom> initrd /boot/initrd.img-2.6.27-rc5-amd64 grubdom> boot block error -1 for op 2 close blk: backend at /local/domain/0/backend/vbd/23/51712 [ 0.000000] Initializing cgroup subsys cpuset [ 0.000000] Initializing cgroup subsys cpu [ 0.000000] Linux version 2.6.27-rc5-amd64 [...] [ 0.000000] Command line: [ 0.000000] KERNEL supported cpus: [ 0.000000] Intel GenuineIntel [ 0.000000] AMD AuthenticAMD [ 0.000000] Centaur CentaurHauls [ 0.000000] ACPI in unprivileged domain disabled [...] [ 0.022093] Booting paravirtualized kernel on Xen [ 0.022101] Xen version: 3.2-1
