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

[Justin Sherrill <justin@xxxxxxxxxxxxxxxxxx>]

This is a "wild guess"-style question: If you boot without any USB
devices connected, does the problem go away?

On Sun, Jun 30, 2013 at 5:12 AM, Mihai Carabas <mihai.carabas@gmail.com> wrote:
> 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