4 ms·

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 cod

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?

sebazzz 8y ago
To clarify for Hyper-V: in Hyper-V, even the host OS is virtualized and runs together with the guests at the same level.
burfog 8y ago
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 8y ago
  > 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 8y ago
    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.

4 ms·

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 cod

by bonzini 8y ago

sebazzz 8y ago
To clarify for Hyper-V: in Hyper-V, even the host OS is virtualized and runs together with the guests at the same level.
burfog 8y ago
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 8y ago
  > 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 8y ago
    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.