Wednesday, September 16, 2009

Xen Garden

Before Xen, the best a virtualization platform had done was to scan the code of a running virtual guest, and perform a translation of instructions that were incompatible with the virtualization concept into ones that matched the paradigm.  As you can imagine, this introduces quite a bit of overhead.

Xen challenged this model by moving to a model of paravirtualization.  By forgoing "perfect compatibility", and modifying the guest OS's code to support an alternate set of virtualization-friendly instructions.  This takes the burden off of the hypervisor at run time, and also lets the developers make smarter choices than a one-size-fits-all instruction translator could do (especially when performance is already an issue--it would be counterproductive to run an expensive algorithm at runtime to optimize runtime performance!).

Xen's architecture was built on the premise of mutual distrust, and intended to challenge the notion that hardware-emulating type virtualization platforms had done before.

Xen uses "domains" to host guest operating systems, and Domain 0 is a special domain that handles semi-privileged tasks, removing them from the core of the hypervisor, and facilitating easier development and testing.

With processors supporting virtualization natively now, the big task was to start handling exceptions that indicate that instructions have been executed from an illegal context, and figure out how to execute them in a virtualization-friendly manner.  The fact that Xen is open source was invaluable in this case, because engineers from Intel and AMD, who had the most intimate knowledge of the specific processor's featureset, could directly contribute code.

The IOMMU extends the reach of hardware directly into the virtual environment by providing an abstraction layer through which access permission could be granted, while maintaining the integrity of the virtual environments.

No comments:

Post a Comment