Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am still confused regarding the mechanisms of virtualisation.

I understand why the x86 architecture is/was not by itself virtualisable and why other architectures are (and why the 68k architecture was except for the MC68000 itself etc.).

And then I read about Intel VT-x and AMD V which add virtualisation capabilities to x86.

However, the virtualised CPU appears to be a different CPU than the physical CPU; namely the physical CPU has VT-x while the virtual CPU does not.

While this is not a practical problem (no operating system one typically wants to run in a VM requires VT-x), it does make me wonder whether this constitutes real virtualisation.

The 80386 already had the ability to virtualise a CPU with fewer features than the 80386 itself, the virtual x86 mode. Is VT-x just another layer like that (ring -1, I suppose) or is it real virtualisation?

(What will happen if one wants to virtualise systems that use VT-x? Shouldn't true virtualisation allow for unlimited levels of virtualisation?)

Sorry for a dumb question. Or rather, sorry for a theoretical rather than practical question.

Update: I did this graphic to try to understand this all better:

share|improve this question
Very interesting topic. And it seems like an answerable question, though it may require some more precise definition of terms like "real virtualization" - or maybe what advantages/benefits you would expect to see from real vs. fake/simulated virtualization? – Kara Marfia Jun 23 '09 at 15:27
By "real virtualisation" I mean a situation where the virtualised CPU is identical to the physical CPU. I am just trying to understand this. – Andrew J. Brehm Jun 23 '09 at 15:50
Note that one reason for a host system in Xen and Hyper-V is so that the host system's native drivers can be accessed by guests that know how to access them (and also to help the Hypervisor drive the system). At least this is what I read somewhere. – Andrew J. Brehm Jun 23 '09 at 16:17
up vote 5 down vote accepted

I understand why the x86 architecture is/was not by itself virtualisable.

That is not true at all. It is virtualisable via Binary translation or more commonly referred as Full virtualisation. You emulate every component of a traditionnal computer with a piece of software sitting on top of an OS.

And then I read about Intel VT-x and AMD V which add virtualisation capabilities to x86.

To be more correct, it adds extra virtualisation capabilities. To be precise, it adds processor extensions that allow processing of virtualisation queries faster. It also adds a -1 ring for 64-bits processor since the number of rings went down to 2 with AMD64.

You can virtualize on x86 using "Full virtualisation" (Virtual PC, VirtualBox) or Paravirtualisation (Xen, Hyper-V). The Intel VT/AMD-V allows you to accelerate virtualisation and do "Hardware Assisted Virtualisation".

I don't know what you mean by real virtualisation... any type of virtualisation is real, they enable you to have more then one OS on a single computer. That's what virtualisation is about.

I hope this was clear. Do not hesitate to comment if you want more info.

Edit : If you really want to know a lot more about this, get this book. It taught me everything.

share|improve this answer

Can you explain how exactly Intel VT/AMD-V speeds up virtualisation?

They make the job of the hypervisor easier, by implementing on CPU techniques VMWare et. al. had to do in their binary translation software. For more details about this, Intel has some nice pages:

There are a couple of areas where it makes it easier. Per the above:

  • Address translation The memory space table presented to the operating system had to be artificially segmented on non-VT CPU's. which was done in software. The extensions allow the CPU to directly virtualize the memory space of a VM-guest by allowing multiple linear address spaces. Before these extensions, this was handled at the binary translation layer.
  • CPU privilege levels The extensions allow guests to actually run their code at the correct ring-layer. Before the extensions, code intending to be run in Ring 0 was actually run in Ring 1 or 3 with the fakery provided by the software binary translation layer. The extensions allow guests to run their code actually at their correct Ring level, while providing safe-guards about breaking out of their VM.
  • Interrupt virtualization By allowing VM-guests to handle their own interrupts, it allows the Hypervisor to not get involved with every single interrupt. This makes guests run faster.

These three things greatly simplify writing a hypervisor, and why the likes of KVM and Xen only supported 'full' virtualization on VT processors at first.

share|improve this answer

VT-x and Pacifica accelerates virtualization. Emulated acceleration is an exercise in futility.

VT-x actually gives you some more functionality as well. VMware ESX cannot virtualize 64-bit guests without VT-x since EM64T/Intel64 does not support segmented memory which was necessary for VMware's binary translation. AMD64 Does support segmentation except in Opteron Rev C processors. AMD realized a mistake and fixed it while Intel chose not to.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.