Re: Google Summer of Code

[Venkatesh Srinivas <vsrinivas@xxxxxxxxxx>]

On Fri, Mar 01, 2013 at 10:20:18PM +0530, Mohit Dhingra wrote:
>*Hi All,
>
>I am a final year student, Masters by Research, at Indian Institute of
>Science Bangalore. I want to work in GSoC 2013. I did a survey of projects
>that people did earlier, and I am interested in the projects related to
>device drivers and virtualization. I looked at "porting virtio device
>drivers from NetBSD to DragonFly BSD". I have done a research project on
> virtualization and presented a paper "Resource Usage Monitoring in Clouds"
>in IEEE/ACM Grid in Beijing last year. Can someone please suggest some
>topics related to this which are yet to be implemented on DragonFly BSD?

Hi,

What area(s) of virtualization are you interested in? DFly as a guest?
As a host? What VMMs?

If you're interested in DragonFly as a virtualization guest on
qemu/KVM or an other platform that exports virtio paravirtualized
devices, there is some work left on the virtio guest drivers --

* virtio-blk:
   I cleaned up and brought in Tim Bisson's port of FreeBSD's virtio-blk
   driver in January, based on work dating back to last April. The driver
   works okay, but has a few issues:

** qemu exports a 128-entry virtqueue for virtio-blk; DragonFly as a
    guest doesn't support indirect ring entries and can issue up to 64 KiB
    I/Os, so we can very easily slam into the virtqueue size limit. If we
    force qemu to expose a larger virtqueue, we can reach ~95% of host
    throughput. Virtio supports up to 16k-entry virtqueue, but qemu+SeaBIOS
    can only boot from 128-entry or smaller queues. Adding indirect ring
    support would help w/ bandwidth here; this is a pretty small project.

** virtio-blk currently 'kicks' the host VMM directly from its
    strategy() routine; it may make sense to defer this to a taskqueue. This
    is a tiny change, but understanding the performance implications may
    take a bit longer.

** virtio-blk doesn't support dumps (crash/panics). Fixing this would be
    pretty straightforward and small in scope.

* virtio-net:
   I have a port of virtio-net, again based on Tim's work,
   but it is usually testing as slower than em (e1000) on netperf
   TCP_STREAM/TCP_RR tests. Improving on this port, re-adding indirect
   ring support (much less of a win for virtio-net compared to -blk),
   and implementing multiqueue would perhaps be large enough for a SoC
   project.

* Our virtio drivers don't support MSI-X; this is not a huge deal for
   virtio-blk, but virtio-net would really benefit from it.

* There are other virtio devices; virtio-scsi is a paravirtualized SCSI
   adapter, there is a FreeBSD driver that could serve as a good start
   for a port. virtio-scsi allows multiple targets per-PCI device, which
   is nice, and newer versions of the adapter support multiple request
   queues. Porting this and implementing multiqueue would be a nice 
   project too.

* When running DragonFly as a guest on KVM, we take a lot of VM exits,
   particularly to our host/VMM's APIC device. We could implement a
   kvmclock time source to avoid some timer exits and support for the
   paravirtualized EOI (https://lwn.net/Articles/502176/) in our platform
   code to cut down on VM exits.

---
DragonFly also has a neat mechanism to allow DFly kernels to run as user
processes on itself ('vkernels'). If you are interested in vkernels,
there is a fair bit of performance work that could be done on them:

* vkernels currently use a shadow translation scheme for virtual memory
   for its guests. (see http://acm.jhu.edu/~me/vpgs.c for an example of
   how that interface works). The shadow translation scheme works on
   every x86/x86-64 CPU, but on CPUs w/ second generation virtualization
   (RVI on AMD or EPT on Intel/Via), we can do much better using those
   hardware guest pagetable walkers.

* DragonFly BSD has simple process checkpointing/restore. In 2011, Irina
   Presa worked on a project to enable checkpoint save/restore of a
   virtual kernel
   (http://leaf.dragonflybsd.org/mailarchive/kernel/2011-04/msg00008.html).
   Continuing this GSoC would be pretty neat, the ability to freeze and
   thaw a virtual kernel would allow all sorts of interesting use cases.

* Virtual kernel host code have simple implementations of
   paravirtualized devices, vkdisk and vknet; understanding their
   performance and perhaps replacing them with host-side virtio devices
   might be worthwhile.

---
A brave last project would be to re-implement the Linux KVM (or some
subset-of) interface on DragonFly. If you're interested in this kind
of project, I'd be happy to explain a bit further...


Take care,
-- vs;
http://ops101.org/