[GSOC] Implement hardware nested page table support for vkernels
Mihai Carabas
mihai.carabas at gmail.com
Sat Sep 14 14:04:19 PDT 2013
Hi all,
Right now the vkernel boots up until "Mounting root from ufs:vkd0s0a". I
> will keep debugging it.
>
This last week I've managed to boot-up the vkernel with EPT/VMX enabled
(there were some bugs un how I was manually walking the guest page tables
at a copyin/copyout call). I've also tested my code on different Intel
machines. At the beginning the vkernel was failing due to the fact that the
machine didn't support 1GB pages (these were for the vkernel DMAPs). I
refactor the code to build 2MB pages if 1GB was not supported (detected
through the cpuid instruction).
Another problem was that the vkernel threads were not idle-ing even though
they were executing umtxsleep. This was because umtxsleep was using
addresses sent from userspace, which were virtual addresses of the guest
and needed to be translated to GPA (guest physical addresses).
I also needed to make synchronious invalidation of a pmap entry (be sure
that no one is using the pmap while I am invalidating it). I copied the
pmap_inval_interlock code from the native kernel into the vkernel, but this
code created a very big contention when running the vkernel with more
virtual cpus than the hardware had. Dillon adjusted the yield() code in
order to not be so contended, but still they were running slow (too many
syscalls in order for the virtual CPUs to synchronize). I dropped out the
pmap_inval_interlock and I created a new system call (vmm_guest_sync_addr)
which sets a value to a specific address, synchronizing all the active VMM
cpus (I created a new vmm_cpumask which tracks down all CPUs that run a VMM
thread from the current process). The vkernel now seems to not move too
slowly, or get contended. Dillon will assess the code for my new system
call on Monday. Also he will be dealing with a bug that he has discovered
when running a buildworld on the vkernel.
I made some tests comparing the two vkernels (non-EPT and EPT) and seems
the perfomance is about the same (make nativekernel -j2, tuxload from
stress tests). It remains to look with Dillon at the vkernel perfomance to
see if we can improve something or not.
I've polished the code a little and add some comments here and there, in
the places where important hooks reside. All my code is in my repos now.
In /usr/src/test/vmm/vmm_test.c I've developed a simple test program that
builds it's own pagetable and enters VMM mode and executing code in there.
It's very simple and helped me get things working.
Thanks,
Mihai
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20130915/86a54e2d/attachment-0002.html>
More information about the Kernel
mailing list