Graphics and I/O virtualization

A colleague of mine just pointed out a neat screenshot from Jacob Hansen, whom I had the pleasure of meeting at SOSP. Rich virtualization of I/O in general, and graphics in particular, remains a pretty wide open area. While Workstation 5.5 includes some basic support for passing the host's video hardware through to the guest, the user experience is still recognizably VMware-esqe; i.e., the guest runs in a big opaque rectangle inside a GUI, or in full-screen mode, but the 'in between' possibilities are largely unexplored.

There's also an instructive discussion taking place over on Xen-devel. One of the interesting things about graphics cards is that they present a relatively natural place to exploit paravirtualization techniques; since all OS'es have well-defined graphics driver APIs, and graphics performance has a huge impact on the user experience, the risk/reward of "true virtualization" (e.g., deciding to precisely emulate a Matrox Flibbertigibbet 2000) vs. pseudo-virtualization (emulating some made-up device that makes getting bits out of the guest and onto the host display hardware easy and fast) strongly favors the latter. The same is true, albeit to a lesser extent, with storage controllers and networking adapters.

The downside of making up your own hardware is that guest OS installers can't find a driver for your pseudo-device; since running an installer is often the first experience a user has with VMware, we want to get that guest installed, on the web, and generally looking smooth as quickly as possible. For that reason, we have a "morphing" network card. The network card initially looks like an AMD Lance, and can be driven by the stock Lance drivers available with everything after Windows for Workgroups or so. However, once you install the VMware tools in the guest, we install a driver that colludes with the Lance, to use a more streamlined, paravirt style I/O path.