Yes, that's what I'm saying.
No, the instructions are not handled by the guest OS as the CPU is paravirtualized. That means the guest runs directly on it. VMware never emulated CPU's what would mean that the instructions are going through the host OS. What runs in the guest is the Virtual Machine Monitor (VMM) and the scheduling. So the guest is independent of the host OS.

But you need VT/V enabled:

If you have a processor which don't has Intel VT/AMD-V:
The VMM runs in Ring 0, a very privileged CPU environment, so that it can intercept instructions which may harm the virtual environment (such as: Power Off CPU coming from a guest) or if a different command syntax is used between the rings. It translate them to virtualisation friendly commands. That's called binary translation. The guest OS (which is used to run in Ring 0 itself) runs in a less privileged ring, but still direct on the CPU.

If you have a CPU which supports VT/V and a bare metal virtualization product, like ESX, not VMware Workstation, the VMM runs in some kind of a new Ring, call it -1, and the guest OS runs in ring 0 again. Here the VT/V takes care about these instructions and no binary translation is needed.

If the guest OS is virtualization aware (called paravirtualized), it can take care about these issue itself, by generating virtualization friendly instructions.

In case of a 64 bit guest OS and VMware Workstation there should be no need to enable VT/V in the BIOS as this is not bare metal virtualization (Hypervisor) and VMware still uses binary translation (so nor wrong instructions hit the CPU) but as far as I know enabling VT/V provides some memory handling code which is still needed by VMWare. But I'm not sure here. If someone can fill the gap....feel free.


If you found this information useful, please consider awarding points for "Correct" or "Helpful" answers/replies. Thanks!!

Edited by AWo