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