I believe I have found a bug in the BHyVe VMX implementation for
Intel platform. Following is the details.

In sys/amd64/vmm/intel/vmx.c, there are three functions, vmx_enable
(line 500), vmx_disable (line 462), and vmx_restore (line 522), which
respectively enable, disable, and restore VMX on the current
processor. There is also a file scope integer array vmxon_enabled
(line 122) which keeps a record whether VMX on each processor is

I noticed that in function vmx_enable, the kernel sets CR4.VMXE to 1,
executes the VMXON instruction, and then sets the corresponding cell
in vmxon_enabled to 1. That is fine. However, in function
vmx_disable, the kernel executes VMXOFF, clears CR4.VMXE back to 0,
but does not clear the corresponding cell in vmxon_enabled back to 0.
This will cause a problem when the function vmx_restore is called, in
which the kernel executes VMXON again if that the corresponding cell
in that array is 1. That is, it will execute VMXON without CR4.VMXE
being set.

Of course, that is only my understanding of the way how these
functions will be called. If I am wrong, could anyone of you please
advise me how this works? Thanks.

vmx_disable is currently only called on vmm module unload, so vmx_restore/vmx_enable can never be called again after that.


freebsd-virtualization@freebsd.org mailing list
To unsubscribe, send any mail to 

Reply via email to