On Virtualisation and 3D Graphics

I find that I’m using Linux on the desktop more and more. It’s certainly good enough for techy users, and for some non-techy users too. But I still use Windows on a day to day basis, and I’m likely to for the foreseeable future. On the other hand I don’t trust Windows security: there have been too many unfixed problems.

What I really want is to be able to run Windows on top of Linux. That would isolate Windows to some extent. And if I use a virtualised solution, then I’d be able to run other operating systems alongside Windows whenever I want to test something out. Sounds like a good solution.

But I want it to run at a reasonable (near native) speed, and I want to make proper use of my graphics adapter even in guest operating systems. I should be able to play games in Windows Vista.

I had a look through most of the virtualisation solutions listed on Wikipedia. It turns out no solution can do exactly what I want.

Here’s the state of the art:

• Xen, which is what I use on servers, can’t do 3D graphics. There are suggestions in the mailing list about how 3D graphics might be achieved. More on this below. And there’s an interesting bit of work, called Blink.  This lets you use Dom 0 graphics with panes controlled by other Doms. Neat! Unfortunately the source code for this is no longer available; it seems like the repository went away.
• X11-based guests can use VMGL for 3D graphics. Not for Windows. It works with Xen, but can also work with VMWare.
• VirtualBox has the beginnings of support for 3D graphics. At the moment it’s only
• OpenGL on Windows guests on Windows hosts. The most important bits of OpenGL reportedly work.
• VMWare, both Server and Workstation versions, has experimental 3D support. Interestingly, Jacob Gorm Hansen, who developed Blink now works for VMWare. I wonder whether this is also his work. It looks like Xen slipped up in not hiring him.
• KVM doesn’t yet have 3D support, outside of VMGL, but it’s growing so quickly that you can expect it will before long.

After looking at various mailing lists and the solutions above, several mechanisms for exporting 
3D graphics to guest operating systems become  clear:

• You might be able to export a whole graphics adapter to a guest OS. This requires a PCI pass-through mechanism. A sticking point here appears to be that the graphics drivers expect to be resident at particular absolute addresses. So, for this to work you’d need an address translation scheme. You’d also only be able to see one desktop/guest OS at a time: the OS would gain complete control over the graphics.
• Paravirtual drivers. Which is what VMGL looks like. It’s aware that it’s operating in a virtual environment, and passes data to a common underlying subsystem for rendering. This seems to me to be the best mechanism. But Windows is not all about OpenGL.

But, there’s a viable path for Windows. If you had a paravirtual windows driver, it could take Microsoft Direct3D calls, and translate then into OpenGL. This could then be passed through VMGL. Voila!

For other operating sytems, you’d have to do something similar, where they supported a 3D API.

In fact, this wrapper exists in part already. (As it’s under the MIT licence, and it’s for Direct3D 8, I wonder if this found its way into 
VMWare, which supports Direct3D 8.1.)

What remains is the not inconsiderable task of writing a Windows driver, or two, which use the wrapper.

Then I’ll have the environment I want. Anyone interested in writing this for me?