<div dir="ltr">Hello,<div><br></div><div style>This week I started building the vmenter/vmexit logic of a virtual machine. The logic state in this moment is unstable and not all operation needed for a vmlaunch are done. So it's work in progress (I'm still talking to vsrinivas about some state information).</div>
<div style><br></div><div style>What I've concretely made:</div><div style>- made a new syscall vmm_guest_ctl from which a thread can call to instruct the VMM to made it a special VMM thread (td_type field - TD_TYPE_VMM_GUEST) and instantiate it's internal structure (td_vmm field from "struct thread"). For td_vmm I used an "void *unused" field  after consulting with vsrinivas if that's ok</div>
<div style>- for instantiating the internal structure, the vmx_vminit is called (there are some interfaces to ensure extensibility with SVM, but this is the final function).</div><div style>- in the vmx_vminit I've allocated the VMCS region and with "vmwrite" I have populated it with different controls (pinbased, procbased, vmentry and vmexit). Also loaded the CR0,CR4 and segment selectors. The RIP it's pointing to the vmx_vmexit function and the RSP to the "vmx_thread_info" structure associated with the current thread to be able to restore the host state.  The CR3 and the base addresses for GDTR,IDTR, GS and TR are loaded at each vmlaunch, because they are per-cpu specific</div>
<div style>- in the x86_64/ipl.s I added a hook which checks the TD_TYPE and issues a vmm_vmenter call just before doing an iret, returning to the virtual machine userspace. </div><div style>- the vmm_vmenter calls the vmx_vmenter which sets up the per-cpu context (the above registers mentioned) and calls the vmx_launch/vmx_resume ASM functions</div>
<div style>- the vmx_launch/resume are implemented in ASM because we have to save/restore HOST/GUEST context and we do not afford to let the compiler take the decisions</div><div style>- before issuing the vmlaunch instruction, we save the HOST state and restore the GUEST state. If it was unsuccessful, the vmlaunch will return with an error. If it was successful, in the end a VM_EXIT will occur and the vmx_vmexit will be called. Here we have to treat the VM_EXIT reason (work in progress)</div>
<div style>- still I have to instantiate the initial GUEST state from the STACK_FRAME (work in progress)</div><div style><br></div><div style>All the code written, still didn't got tested. Probably at the mid of the next week will be in a shape to start testing each component. The short term goal right now is to run a simple program, in the VMX non-root operation mode. Than will start to emulate the access to different MSR registers and cpuid (the vkernel will issue such commands). I will make a more extensive description after I will achieve my short term goal (simple program in VMX non-root operation).</div>
<div style><br></div><div style><br></div><div style>HP Blade: I've made intensive tests with the OCE driver (issued about 100MB/s traffic and in parallel high SSH traffic rate and the behaviour was normal). The EHCI still hangs up at [1] ehci_pci_givecontroller() at line 541 (pci_write_config never returns).</div>
<div style><br></div><div style><br></div><div style>Thanks,</div><div style>Mihai</div><div style><br></div><div style>[1] /usr/src/sys/bus/usb/ehci_pci.c</div><div style><br></div></div>