I’ve previously written about memory squeeze problems in a Xen Dom0 when large amounts of memory were assigned to DomUs [1]. In summary the Dom0 would have problems if started with default options and the majority of the RAM was later assigned to DomUs, but if the memory of the Dom0 was limited by the dom0_mem parameter to the Xen kernel then things would work well.
Fatal server error:
xf86MapVidMem: Could not mmap framebuffer (0xfae80000,0x80000) (Invalid argument)
I have since found another exciting bug with Xen. I was in the process of upgrading an AMD64 workstation to using Xen so that I could test other versions of some software in the background. The first stage was to install the Xen kernel and the Xen enabled Linux kernel and boot the machine. Unfortunately I then received the above message when trying to start the X server. I discovered the solution to this in the comments section of Different Colours blog post about Virtualisation on Lenny [2]. It seems that there is a problem gaining mmap access to MMIO memory regions in Xen and that restricting the memory of the Dom0 is a work-around.
My AMD64 workstation has 3G of RAM because the motherboard can’t support more than 3.25G and buying 4G of RAM to have 3.25G usable would be an expensive way of doing it. So I used dom0_mem=1500M and now X works again. I have yet to discover if anything strange and exciting happens when I create DomUs on the machine. I don’t have any immediate plans for running Xen on the machine. It’s main uses at the moment is torcs (a slightly realistic 3D car racing game), supertuxkart (a cartoon 3D car racing game), and mplayer so it doesn’t really need a lot of RAM.
I like to keep my options open and have all my machines capable of virtualisation apart from routers.