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

[Mihai Carabas <mihai.carabas@xxxxxxxxx>]

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

Hello,

This week I build the initialization procedure for VMX. What I've been
following:
- detect if there is any support for VMX
- detect if the VMX isn't disabled by the BIOS
- detect and save in predefined variables the VMX capabilities of the CPU
- extract the VMX region size used by the vmxon operation
- extract the VMX version
- fix CR4 and CR0 registers on each CPU
- enable VMX operations by setting the CR4.VMXE on each CPU

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.

I also exposed some data through sysctl, and more will be added:
root@dfly_x86-64:~# sysctl -a|grep vmm
hw.vmm.vmx.revision: 16
hw.vmm.vmx.region_size: 1024
hw.vmm.vmx.width_addr: 0
hw.vmm.type: VMX from Intel
hw.vmm.enable: 1

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.

There is an editable sysctl, hw.vmm.enable, which can turn on/off the VMM
(in the case of VMX, it executes vmxon/vmxoff).

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.

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.

Thanks,
Mihai

--089e01175e7725dcec04e05b84be
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 build the init=
ialization procedure for VMX. What I&#39;ve been following:</div><div style=
>- detect if there is any support for VMX</div><div style>- detect if the V=
MX isn&#39;t disabled by the BIOS</div>
<div style>- detect and save in predefined variables the VMX capabilities o=
f the CPU</div><div style>- extract the VMX region size used by the vmxon o=
peration</div><div style>- extract the VMX version</div><div style>- fix CR=
4 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 buil=
t the vmx region for each CPU (these have to exists on a per-cpu basis) and=
 execute &quot;vmxon&quot; operation on each CPU. After some struggling wit=
h errors like &quot;general-fault protection&quot; (verified wrong MSRs or =
written the wrong bits in CRx), I managed to successfully execute a vmxon o=
peration. The system is running now in VMX-root operation mode.</div>
<div style><br></div><div style>I also exposed some data through sysctl, an=
d more will be added:</div><div style><div>root@dfly_x86-64:~# sysctl -a|gr=
ep 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><d=
iv>hw.vmm.enable: 1</div><div><br></div><div style>The subtree coresponding=
 is the &quot;vmm&quot; one which is populated dynamically, depending on wh=
at 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/vmxof=
f).</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 anythi=
ng.</div>
<div style><br></div><div style>As for the HP blade, it reboots now if I ma=
nually unload the ehci.ko module. Can anyone suggest what might be the prob=
lem? 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 trou=
bles accessing the cluster with the HP blade, I didn&#39;t get to do them. =
I promiss that tomorrow night I will run the tests and then swildner can co=
mmit to upstream the drivers.<br>
</div><div style><br></div><div style>Thanks,</div><div style>Mihai</div></=
div></div>

--089e01175e7725dcec04e05b84be--