Life in Code

Some interest in my presentation at the Linux Foundation Collaboration Summit led to an interview and article written by Beth Pariseau of Techtarget. The article is interesting and relevant but the topic of hypervisors is technical and hard to present in a news format. Some of the information provided to Ms. Pariseau by others is not correct, in my opinion but she does a good job presenting opposing viewpoints and a great job overall on the short article.

One particular quote (two years old) from Andi Mann is wrong on virtually every point:

“Xen is run and managed at a lower level (ring 0), even for new virtual machine creation, and guests do not share memory blocks, CPU instructions or any of the underlying (albeit occasionally de-privileged) Linux operating system like KVM does. This means KVM suffers performance, latency, security, scalability, isolation and other issues that do not affect a true bare-metal hypervisor.”

Let’s take these claims one at a time:

1. “Xen is run and managed at a lower level (ring 0).” This is egregiously wrong – KVM is run and managed at Ring 0 as are all hypervisors that use Intel VMX or AMD SVM instructions. See slides # 8 and 19 in my presentation kvm-not-what-you-heard or any recent systems’ programmers guide from Intel or AMD.
2. “Guests do not share memory blocks, CPU instructions, or any of the underlying Linux operating system like KVM does.” This is also egregiously wrong. Xen guests share memory blocks with Xen paravirtual I/O drivers, which are almost always hosted in the Linux Domain 0 kernel and shared among all guests. The vast majority of all Xen guests all share an entire Linux operating system — Domain 0– that does all I/O and device emulation. The vast majority of all Xen guests share common device drivers. They share the same code emulator. Even the very few Xen geusts that use the Stub domain code share memory blocks with each other and with the Xen kernel using Xenbus. KVM guests also share code, device drivers, and memory blocks. This is not a problem, it is normal, accepted kernel engineering practice. All widely used kernels do this. It is secure because of hardware memory protection.
3. “KVM suffers performance, latency, security, scalability, isolation, and other issues that do not affect a true bare-metal hypervisor.” First of all, KVM is a true bare-metal hypervisor. But that doesn’t prove anything, because bare-metal hypervisors may also be vulnerable to “latency, security, scalability, isolation, and other issues” if they are mis-designed or if they suffer from programming errors. So this statement is meaningless. The fact is that KVM has performance advantages over both Xen and VMware (see SPECVirt results, for example.) Xen has a huge isolation issue with Domain 0 (See slides #20-23 in my presentation referenced above).

You should dismiss factual errors, such as the ring 0 statement, out of hand. You should disregard these further statements by Mann unless he provides evidence, data, or explanation.