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

Justin Sherrill <[email protected]>
Newsgroups gmane.os.dragonfly-bsd.kernel
Message-ID <CA+YR8=2paLuLSwmH_VFA2Qpe1LtrQGBBmPFJT11j+pJ+Y3yC2g@mail.gmail.com>
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 <[email protected]> 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.