<div dir="ltr">Hello,<div><br></div><div style>This week I build the initialization procedure for VMX. What I've been following:</div><div style>- detect if there is any support for VMX</div><div style>- detect if the VMX isn't disabled by the BIOS</div>
<div style>- detect and save in predefined variables the VMX capabilities of the CPU</div><div style>- extract the VMX region size used by the vmxon operation</div><div style>- extract the VMX version</div><div style>- fix CR4 and CR0 registers on each CPU</div>
<div style>- enable VMX operations by setting the CR4.VMXE on each CPU</div><div style><br></div><div style>Using the data presented above I have built the vmx region for each CPU (these have to exists on a per-cpu basis) and execute "vmxon" operation on each CPU. After some struggling with errors like "general-fault protection" (verified wrong MSRs or written the wrong bits in CRx), I managed to successfully execute a vmxon operation. The system is running now in VMX-root operation mode.</div>
<div style><br></div><div style>I also exposed some data through sysctl, and more will be added:</div><div style><div>root@dfly_x86-64:~# sysctl -a|grep vmm</div><div>hw.vmm.vmx.revision: 16</div><div>hw.vmm.vmx.region_size: 1024</div>
<div>hw.vmm.vmx.width_addr: 0</div><div>hw.vmm.type: VMX from Intel</div><div>hw.vmm.enable: 1</div><div><br></div><div style>The subtree coresponding is the "vmm" one which is populated dynamically, depending on what virtualization extension we have (for now only VMX). As you can see the region_size is 1024(1K), the width_addr means that the addresses used must have the processor length in bits (not important in this case) and the vmm_type is completed statically with the name of the extension.</div>
<div style><br></div><div style>There is an editable sysctl, hw.vmm.enable, which can turn on/off the VMM (in the case of VMX, it executes vmxon/vmxoff).</div><div style><br></div><div style>I also had some troubles with the sysctl, as I was trying to clean-up a node from a sysctl PROC, which ended up with a self-deadlock. I modified the design to not have to delete anything.</div>
<div style><br></div><div style>As for the HP blade, it reboots now if I manually unload the ehci.ko module. Can anyone suggest what might be the problem? Also swildner managed to bring up an OCE driver for my 10gbit network card. sephe recommended some tests but due to the fact that I had some troubles accessing the cluster with the HP blade, I didn't get to do them. I promiss that tomorrow night I will run the tests and then swildner can commit to upstream the drivers.<br>
</div><div style><br></div><div style>Thanks,</div><div style>Mihai</div></div></div>