Google Summer of Code

Tue Mar 5 01:45:12 PST 2013

*Hi Venkatesh,*

Thanks a lot for a nice explanatory mail!

I found the second project quite interesting, just to repeat  --
** 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.

As per my understanding, the notification to host through kick() involves
the exit of the guest (as per attached paper). Hence, the aim for this
project would also be to minimize the exits, or rather instantaneous exits.
Deferring it to the task queue should definitely help. Other things that
can be done in this project is batching of the buffers before kick() and
dynamically deciding how many buffers can be batched together.

Also, not all of the times deferring the 'kick' to taskqueue might not be a
good idea. Finding those scenarios would be interesting where it helps, and
where it is merely an overhead.

I am also interested in performance analysis for the same. It would be
great if you can point me to some more references to gain the prerequisite
knowledge for the same.

*
----------------------------
Thanks & Regards
Mohit Dhingra
+919611190435*

On 5 March 2013 04:39, Venkatesh Srinivas <vsrinivas at ops101.org> wrote:

> 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/<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<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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20130305/10f02b13/attachment-0003.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 32_virtio_Russel.pdf
Type: application/pdf
Size: 188685 bytes
Desc: not available
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20130305/10f02b13/attachment-0020.pdf>