[GSOC] Implement hardware nested page table support for vkernels

Mihai Carabas mihai.carabas at gmail.com
Sun Jul 7 07:58:53 PDT 2013


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).

What I've concretely made:
- 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
- for instantiating the internal structure, the vmx_vminit is called (there
are some interfaces to ensure extensibility with SVM, but this is the final
- 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
- 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.
- 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
- 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
- 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)
- still I have to instantiate the initial GUEST state from the STACK_FRAME
(work in progress)

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).

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).


[1] /usr/src/sys/bus/usb/ehci_pci.c
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20130707/cee27295/attachment.html>

More information about the Kernel mailing list