[burfog]

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.

[mappu]

> 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).

[souprock]

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.