Re: [GSOC] Implement hardware nested page table support for vkernels

[Mihai Carabas <mihai.carabas@xxxxxxxxx>]

--f46d044402689e794504e0ed2a4b
Content-Type: text/plain; charset=ISO-8859-1

Hello,

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


Thanks,
Mihai

[1] /usr/src/sys/bus/usb/ehci_pci.c

--f46d044402689e794504e0ed2a4b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hello,<div><br></div><div style>This week I started buildi=
ng the vmenter/vmexit logic of a virtual machine. The logic state in this m=
oment is unstable and not all operation needed for a vmlaunch are done. So =
it&#39;s work in progress (I&#39;m still talking to vsrinivas about some st=
ate information).</div>
<div style><br></div><div style>What I&#39;ve concretely made:</div><div st=
yle>- made a new syscall vmm_guest_ctl from which a thread can call to inst=
ruct the VMM to made it a special VMM thread (td_type field - TD_TYPE_VMM_G=
UEST) and instantiate it&#39;s internal structure (td_vmm field from &quot;=
struct thread&quot;). For td_vmm I used an &quot;void *unused&quot; field =
=A0after consulting with vsrinivas if that&#39;s ok</div>
<div style>- for instantiating the internal structure, the vmx_vminit is ca=
lled (there are some interfaces to ensure extensibility with SVM, but this =
is the final function).</div><div style>- in the vmx_vminit I&#39;ve alloca=
ted the VMCS region and with &quot;vmwrite&quot; I have populated it with d=
ifferent controls (pinbased, procbased, vmentry and vmexit). Also loaded th=
e CR0,CR4 and segment selectors. The RIP it&#39;s pointing to the vmx_vmexi=
t function and the RSP to the &quot;vmx_thread_info&quot; structure associa=
ted with the current thread to be able to restore the host state. =A0The CR=
3 and the base addresses for GDTR,IDTR, GS and TR are loaded at each vmlaun=
ch, because they are per-cpu specific</div>
<div style>- in the x86_64/ipl.s I added a hook which checks the TD_TYPE an=
d issues a vmm_vmenter call just before doing an iret, returning to the vir=
tual machine userspace.=A0</div><div style>- the vmm_vmenter calls the vmx_=
vmenter which sets up the per-cpu context (the above registers mentioned) a=
nd calls the vmx_launch/vmx_resume ASM functions</div>
<div style>- the vmx_launch/resume are implemented in ASM because we have t=
o save/restore HOST/GUEST context and we do not afford to let the compiler =
take the decisions</div><div style>- before issuing the vmlaunch instructio=
n, we save the HOST state and restore the GUEST state. If it was unsuccessf=
ul, the vmlaunch will return with an error. If it was successful, in the en=
d a VM_EXIT will occur and the vmx_vmexit will be called. Here we have to t=
reat the VM_EXIT reason (work in progress)</div>
<div style>- still I have to instantiate the initial GUEST state from the S=
TACK_FRAME (work in progress)</div><div style><br></div><div style>All the =
code written, still didn&#39;t got tested. Probably at the mid of the next =
week will be in a shape to start testing each component. The short term goa=
l 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 descr=
iption after I will achieve my short term goal (simple program in VMX non-r=
oot operation).</div>
<div style><br></div><div style><br></div><div style>HP Blade: I&#39;ve mad=
e 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 stil=
l hangs up at [1]=A0ehci_pci_givecontroller() at line 541 (pci_write_config=
 never returns).</div>
<div style><br></div><div style><br></div><div style>Thanks,</div><div styl=
e>Mihai</div><div style><br></div><div style>[1]=A0/usr/src/sys/bus/usb/ehc=
i_pci.c</div><div style><br></div></div>

--f46d044402689e794504e0ed2a4b--