[GSOC] Make vkernels checkpointable

[Irina Preșa <irina.presa@xxxxxxxxx>]

Hello,

My name is Irina Presa and I am a final year undergraduate student from
University Politehnica of Bucharest, Romania, Computer Science and
Engineering Department.

After reading the article "Virtual Kernel Peek" [1], I found vkernel
architecture quite impressing. I've also noticed the "Make vkernels
checkpointable" project on GSOC page and I would be really happy to work
on it.
I'm a beginner in kernel programming, so I would like to know if you
think I might be suitable for this project. This semester in school, I
am attending my first kernel architecture course and I find it
fascinating. As for further OS knowledge, last year I had a course of
system programming (mostly operating systems concepts applied from
userland using POSIX or WIN API). I've also followed Assembly and
Compilers courses.

About this project, after browsing the sources and the mailing list I
came to the following conclusions:

Basically, the save and restore of segment registers (especially the TLS
support) seems to be the most "sensitive" part. I am not very familiar
with this subject (besides the theoretical part I've learned in school)
and I would like some advices in this direction. From the mailing list I
got to this implementation[2]. Apparently, a starting point would be
adding another field in the elf core dump (prsavetls_t tls), that keeps
the tls info and stores it from each thread
bcopy(&lp->lwp_thread->td_tls, tls, sizeof *tls)). I also found this
linux patch[3] which might make a good reference since it implements
thread saving and restore successfully. Wouldn't be necessary to also
load the tls in the Global Descriptor Table?

As for the recreation of the vmspaces, I read here[4] that "it should be
possible to do without any modification of the real kernel", allowing
the vkernel to save the vpagetable information. Is that a valid solution
or we will go by the one described in the gsoc page? Of course, using
the host kernel's checkpoint facility in order to save the VPAGETABLES
offset and map type shouldn't be a problem, but I thought it would be
better to isolate the vkernel as much as possible. As for the vkernel's
part, I'm guessing that some cpu_vmspace_alloc calls (that will call the
corresponding syscall in order to ask host kernel to do the mappings)
using the checkpointed offsets should be enough.

And for the last part the dump/load of the current state of network and
console drivers I browsed the source code and noticed that:
For the network drivers I might need to save the
interface/address/netmask/bridge(maybe reading them with ioctl calls)
and on restore to reopen each interface (netif_open_tap) and reset it's
parameters (netif_init_tap) as the methods from init.c do. The console
code would do something similar using termios getattr and setattr.

I would be glad to know your opinion on the above, and if you can
provide me a starting point - some further reading or even some kernel
tests that I could try.

Best regards,
Irina

[1]http://www.dragonflybsd.org/docs/developer/VirtualKernelPeek/
[2]http://gitweb.dragonflybsd.org/~sjg/dragonfly.git/commitdiff/e29b6f2d0c961889b55e94ce7ac6aa0e398d7071
[3]http://www.mail-archive.com/linux-api@vger.kernel.org/msg00994.html
[4]http://article.gmane.org/gmane.os.dragonfly-bsd.kernel/13661/match=checkpoint+vkernel