AMD的虚拟化技术

 AMD Virtualization Technology

As virtualization becomes more popular, it's important that it become faster, more secure, and more efficient. That's the goal of AMD's Virtualization technology, which takes some tasks that virtual machine managers (VMMs) perform in software, through emulation, and simplifies them through enhancements to the AMD Athlon 64 and Opteron instruction set. AMD Virtualization Technology was announced in 2004, under the code-name Pacifica , and AMD released technical details in mid-2005. Processors using this technology are expected to appear in 2006.

Let's talk for a moment about virtualization. In a modern-day virtualization system, such as that offered by VMware server and workstation software, in Microsoft's Virtual PC or Virtual Server, or the open-source Xen virtualization system, a thin layer of software, called the virtual machine manager or hypervisor (both terms are common) runs on the processor. The VMM then creates a number of virtual machines, into which it loads a standard, unmodified operating system, such as Linux, Solaris, or Windows.

Each virtual machine is allocated specific resources, such as memory pages, disk storage, and virtualized I/O connectivity, such that it thinks it's running on the bare metal, and has the computer entirely to itself. However, the VMM is constantly monitoring the execution of the virtual machines, interceding to redirect memory, storage and I/O requests to the specific allocated resources (think of paging, as an example), and emulating hardware interrupts that might let the software running within one virtual machine affect what's happening in another virtual machine, or even compromise the stability of the VMM itself. This software emulation includes, by the way, rewriting instructions, substituting instructions, changing calling parameters—there's a lot of stuff going on behind the scenes at the virtual machine manager level.

Making this software emulation work is tricky, because of the design of the x86 architecture. Traditionally, there are two ways that code can run. One mode, called "privileged" or Ring 0 mode, is generally used by operating system kernels and device drivers; the processor lets privileged code have full, unfettered access to all hardware resources. The other mode, called "user" or Ring 3 mode, is generally used by non-kernel, non-driver OS code and by applications; software running in user mode is constrained to running within specific parameters set by the privileged code.

For example, only privileged code can define memory-mapping parameters or set up interrupt handlers. When user code calls an interrupt, the processor passes control to privileged code to handle the request. Error conditions also pass control to privileged code.

Keeping Control

All modern operating systems expect that their kernel and driver code is running in privileged mode, which of course is fine in a non-virtualized PC. However, in a virtual machine, you don't want that kernel and driver code, or the interrupt handlers, to really have full control over the hardware; you need the VMM to be able to be able to transparently manage the system. But because both the VMM itself, and the virtualized guest operating system kernel and drivers are running in Ring 0—in other words, they're peers—the VMM has to do a lot of work to maintain control of the guest operating system. Thus, the emulation, and the performance hit that it represents.

Virtual machine technology, as I've described it, has been around for a decade or so—and is solid and mature, with many enterprises using VMMs from VMware, Microsoft, and Xen for desktops, small-business servers and for massive enterprise data centers. However, this approach remains suboptimal, because of the extensive need for software interception and emulation by the VMM, which chews up CPU cycles, cutting into performance.

Given that advanced processor architectures, like AMD's dual-core designs, lend themselves beautifully to hosting virtualization—the HyperTransport bus lets each virtual machine have a lot of IO bandwidth and speeds up core-to-core communications—it's a shame to slow the system down with software emulation.

That's where AMD Virtualization Technology comes in. It comprises a set of instructions and architectural constructs that solve several of the thorniest problems in VMM software emulation of things like IO calls or interrupt handling. In effect, they create a superprivileged mode (sometimes referred to as "Ring -1"), which can only be used by the VMM. Because virtual machines and guest operating systems and applications continue to use traditional privileged and user modes, the VMM now has unique abilities to control the execution of virtual machine code running in Ring 0—without software emulation. Let's see how it works.

Virtual Machine Run, Run, Run

When a desktop, notebook or PC boots up in a non-virtualized mode, the platform loads and runs the traditional operating system, running in privileged Ring 0 mode. The same is true with running one of today's virtualization systems: the hardware loads up the VMM kernel, which runs in Ring 0. But with the new Virtualization technology, the hardware will load up a small Ring 0 stub, which switches the processor into a new mode, called Secure Virtual Machine (SVM) mode. That's AMD's real name for what I was calling the superprivileged Ring -1 mode.

In SVM mode, the VMM has unique control over new parts of the processor. For example, when it creates a new virtual machine instance, the VMM software defines a Virtual Machine Control Block for that virtual machine. The VMCB, which defines the parameters and capabilities of a specific virtual machine, is only visible in the Ring -1 mode. The VMM can also set up memory access using a new nested page-table support; in other words, each virtual machine will have its own page table, which looks like it's real, but which has secret offsets and access restrictions set up by the VMM.

Similarly, while running in SVM mode, the VMM can define, for each virtual machine, which I/O channels are visible, and which are invisible, and how they perform. (To see how the VMM can do all these things, see the AMD's "AMD I/O Virtualization Technology (IOMMU) Specification.")

Once a virtual machine has been defined, the VMM passes control to that virtual machine through the new VMRUN instruction, which saves the VMM processor state, reads the control bits from the VMCB for the appropriate virtual machine, and then begins running the virtual machine's code in standard privileged and user code, as requires. AMD calls this "guest mode."

While running in guest mode, the processor uses the virtual machine definitions created in the VMCB to manage the virtual machine's guest operating system and applications automatically, translating arguments and relocating system resources in hardware, without needed intervention from the VMM. This is what makes the Virtualization approach so much faster than traditional emulated virtual machine managers.

However, from time to time, the guest operating system and its applications will need things that the VMM needs to think about, such as handling an error, an illegal operation, or an interrupt. Even here, however, Virtualization works to make this fast and efficient. If the guest operating system causes a fault or some types of interrupts, the processor exits guest mode and rapidly switches back to SVM mode, loading the saved VMM state. The VMM can then process the virtual machine's interrupt or resolve the resource conflict, and then return control to the virtual machine through the VMRUN command again.

It's an elegant system, and designed for both speed and stability. Each time the VMM calls VMRUN to pass control to a virtual machine, the processor performs consistency checks on the SVM and guest states, making sure that everything is running okay. If not, it exits back to the VMM with an error condition, letting the VMM then decide how to fix things. In other words, the VMM is in control—and the hardware architecture works hard to keep it that way.

Taking Virtualization to the Next Level

AMD's Virtualization technology, expected to ship in the AMD Athlon 64 and Opteron processors in 2006, should offer tremendous benefits for any enterprise that uses desktop or server virtualization. All three of the major VMM makers, VMware, Microsoft (for both Virtual PC and Virtual Server), and XenSource, will support Virtualization technology within their VMM platforms. It's going to make a huge difference.