Hacker News new | ask | show | jobs
by burfog 2810 days ago
Last I checked, every virtualization driver ignored Intel's overcomplicated design choice. They don't keep things going; if they did then they would clash with each other. Instead, they fully shut down virtualization when the VM isn't running code.

Intel seems to have accepted this state of affairs. On newer chips, it is much faster to enable and disable virtualization.

2 comments

No, this is not true. KVM always keeps VMX on, Xen too even when running paravirtualized guests, Hyper-V does not even have a concept of "the VM not running code". Maybe VMware Workstation and VirtualBox?
To clarify for Hyper-V: in Hyper-V, even the host OS is virtualized and runs together with the guests at the same level.
Well, I'm part of a team that maintains a VMX driver, and we've looked at what the competition did. It's been a while since we did that, so change is possible. Hyper-V might be special.

We could be talking past each other. Here, to clarify, are 3 methods:

x. The driver never does VMXOFF.

y. The driver does VMXON when asked to run a guest. The driver may handle events from the guest (such as page faults or CPUID emulation) without doing VMXOFF, but the driver will do a VMXOFF prior to letting other host processes and drivers run.

z. The driver does VMXOFF every time the VM exits.

We found that choice x was not normally used. If it were, then VMX drivers would not be able to coexist with each other. I'm not saying that everybody uses choice z. Choice y is probably also popular.

> If it were, then VMX drivers would not be able to coexist with each other.

Most VMX drivers are unable to coexist (in the sense that VirtualBox, HAXM, Hyper-V, and VMWare Player are mutually incompatible / can't be used in the same Windows boot session).

I just checked a proprietary VMX driver.

It fully disables VMX before turning interrupts back on.

If I remember right, it works fine with VMWare running on the same machine, so they must be doing likewise. I think I recall problems with Hyper-V, so you are probably right about that one. It looks like Hyper-V is the uncooperative VMX driver that refuses to play nice with others.

To build on bonzini's answer there are multiple types of virtualization.

What mainframes have done for years and modern PC VMs do, is type 1 virtualization, whereas stuff like Virtual Box is type 2 virtualization.