Virtualization in Xen 3.0
VT-x/VT-i and AMD's SVM architectures have much in common, which was the motivation for developing their common interface layer, the Hardware Virtual Machine (HVM). The code for the HVM layer was written by Leendert van Doorn from the Watson Research Center at IBM, and it resides in a separate branch in the Xen repository.
An example of a common interface for VT-x/VT-i and AMD SVM is the domain builder, xc_hvm_build(), located in xc_hvm_build.c. Because the loader now is common to both architectures, the vmxloader now is called the hvmloader. The hvmloader identifies the processor simply by calling its CPUID; see tools/firmware/hvmloader/hvmloader.c.
The AMD SVM has a paged real mode, which virtualizes a real mode inside of a protected mode. So in the case of AMD SVM, we should set operations to real mode only, SVM_VMMCALL_RESET_TO_REALMODE. In the case of VT-x/VT-i, we should use VMXAssist, as explained above.
HVM defines a table called hvm_function_table, which is a structure containing functions that are common to both VT-x/VT-i and AMD SVM. These methods, including initialize_guest_resources() and store_cpu_guest_regs(), are implemented differently in VT-x/VT-i and AMD SVM.
Xen 3.0 also includes support for the AMD SVM processor. One of SVM's benefits is a tagged TLB: guests are mapped to address spaces different from what the VMM sets. The TLB is tagged with address space identifiers (ASIDs), so a TLB flush does not occur when there is a context switch.
One of the fascinating features of Xen is live migration, which can be used as a solution for load balancing and maintenance. The downtime when using live migration is quite low--tens of milliseconds. Live migration implementation in Xen is managed by domain 0.
There are two stages to live migration. The first stage is "pre-copying", in which the physical memory is copied to the target by way of TCP while the migrating domain continues to run. After some iterations, during which only the pages that were dirtied from the last iteration are copied, the migrating domain stops running. Then, in the second stage, the remaining pages are copied, and the domain resumes its work on the target machine.
In addition, Jacob Gorm Hansen, from the University of Copenhagen, Denmark, is doing some interesting work on "self migration". In self migration, the unprivileged domain being migrated handles the migration itself. Although there are some benefits to having this ability, such as security, self migration is more complex than live migration. For instance, the memory pages containing the code that manages the migration are dirtied during the transfer.
In the future, it appears as though all of Intel's new 64-bit processors will have virtualization extension support, and Xen seems to adopt mainly CPUs with virtualization support. Currently, Xen has support for VT-x and VT-i in the official tree, and a branch in the repository has AMD SVM support.
Overall, Xen is an interesting virtualization project with many features and benefits. And, there's a chance that Xen will be integrated into the official Linux kernel tree sometime in the future, as happened with UML and LVS.
Rami Rosen is a computer science graduate of Technion, the Israel Institute of Technology, located in Haifa. He works as a Linux kernel programmer for a networking start-up, and he can be reached at email@example.com. In his spare time, he likes running, solving cryptic puzzles and helping everyone he knows to move to this wonderful operating system, Linux.
- Server Hardening
- Unikernels, Docker, and Why You Should Care
- diff -u: What's New in Kernel Development
- Controversy at the Linux Foundation
- 22 Years of Linux Journal on One DVD - Now Available
- Non-Linux FOSS: Snk
- Giving Silos Their Due
- Don't Burn Your Android Yet
- What's New in 3D Printing, Part III: the Software