In Joisey

I'm currently in Jersey and have found some time to do a little hacking. The current distraction is libxend. There are a few reasons I'm spending time on it. The first is that it's a lot of easy work which makes it ideal for a few minutes here and there of hacking. Second is that I need it for a project I'm working on at IBM. A big part of this is too is that I really want to build my own tool chain again--not a public one like vm-tools but just something that I can use. I really dislike the xm interface. I don't want to use configuration files or anything of that junk. I particularly despise the xm networking mechanism too.

A Good VM Widget

There's four display modes that I care about for running virtual machines. These names are made up and probably in use by noone but me. The first mode of interest is serial mode. In this case, you assume the guest thinks you have a vt100 terminal connect to the serial port and tell the guest to display the console to that. When dealing with serial mode, you need something capable of rendering a vt100 terminal (which is no small task!).

The second, closely related, mode is CGA mode. In CGA mode, the guest thinks it has a VGA screen attached to it but since it's just displaying text, it uses the old CGA compatibility mode supported by VGA. In this mode, instead of rendering pixels to the screen, the screen is divided into characters with a few simply attributes (and a foreground/background color). There are some aspects of CGA mode that make it far superior to serial mode. Namely, the experience identical to being in front of a physical computer (scroll back works as does VT switching). A down side is that it is identical to being in front of an actually computer (so scroll back is really short and goes away on VT switching). Only some simply drawing primatives are needed to implement CGA mode (rendering a font with certain colors).

The third mode is local VGA mode. In local VGA mode, you're rendering the VGA display (in whatever depth it's setup in) to the local display. In this mode, you can do some interesting pass through of 2d or 3d drawing primatives.

The final mode is remote display mode. In remote display mode, you're on a completely different machine than the VM and the display has to be sent across the network via something like VNC.

Clearly, these four modes present interesting challenges and *no* virtualization solution implements them all well. What would be really cool to see in the future is a single GTK widget that was capable of handling any of these modes. This would help make it possible to build a really nice GUI that Just Worked either as a local or remote management interface.

A neat VFB feature

A patch was recently posted on qemu-devel that allows for the VGA device (when in CGA mode) to be rendered directly by ncurses. It's a pretty neat effect and given a more complete implementation would be really cool.

In fact, I think that long term, for Xen, what I would like is to support this by default and only use the virtual framebuffer if it's enabled by the guest.

Userspace VFB Updates

Gerd Knorr pointed me to a VFB driver he recently wrote for UML. The similiarities are pretty interesting and a good sign that I'm going in a plausible direction. Gerd is doing one thing in his driver that peeks my interest quite a bit.

Userspace VFB writes (ala X) are challenging because userspace gets to map the framebuffer directly into its address space. Since there is not update notification mechanism, this makes it very challenging to determine when the framebuffer should be blitted on screen (and which portions should be blitted). Its terribly wasteful to blit the entire framebuffer 30 times a second and even more wasteful to try and map that to something like VNC.

I had briefly considered using demand paging to work around this problem. Linux's mmap() is lazy in that it only maps pages when they are first read/written. You could potentially trap writes by changing the mappings to be read-only or even just not actually map the pages.

Of course, you want to avoid taking a hit for every single byte read/write. I figured this was going to be challenging and put it off. Gerd, however, has found a simple and clever approach. Gerd uses a timer that fires at the FPS rate and if there was a page that has been mapped in since then, he removes the mapping and issues appropriate updates. That's it. It's quite simple and yet also quite powerful. It has all the right properties too of little-to-no performance overhead when the display is idle. I'll certainly be adopting it for the Xen VFB.

A Bit ADD

I can definitely be ADD sometimes. I haven't worked on the VFB for a few days now mostly from studying. I have some free time today which resulted in me playing around with iCal. It's pretty cool stuff.

It makes me wonder why we don't have /var/spool/calendar and proccalendar...

Xen Attracts a Crowd

One of the really interesting things about the Xen project is that there are a ton of big name folks involved in it in some way or another. While this is generally an awesome thing (you get a bunch of awesome information you could get nowhere else), it sometimes means simple conversations end up becoming major holy wars.

Xen Virtual Framebuffer

I posted my first version of a Xen Virtual Framebuffer today. Hopefully this will lead to lots of pretty GUIs that makes Xen as accessible to the average user as a product like VMware. It's amazing how much people love VMware. This weekend someone who I had never met before spent 10 minutes telling me how his company couldn't exist without it.

I think a large part of that is ease of use. He really didn't care if it was slow, or expensive, or whatever. It Just Works. It's a bit early for New Years resolutions, but focusing on ease-of-use is going to be mine.

If you're interested in the VFB stuff, check out http://wiki.xensource.com/xenwiki/VirtualFramebuffer.

Virtual Framebuffers

One really neat thing that we do at IBM is have weekly architecture calls often with guest speakers. This combines the LTC and Research together and is often a place where really cool things are discussed.

Jimi was able to arrange for Ricardo Baratto from the NCL at Columbia to give a presentation on THINC this week. I wasn't able to attend due to class but after reading a couple of the papers on it, I grew a new interest in a different approach to para-virtual framebuffers.

Apparently, the framebuffer interface in Linux is butt-simple and I was able to hack up a pretty quick vmalloc() based framebuffer. I'm currently plumbing it up within Xen and will hopefully have a demo soon.