[gsoc] Virtio progress

Stéphanie Ouillon stephanie at minet.net
Sun Jun 19 13:28:23 PDT 2011


Here is what I worked on during the last two weeks.

I kept on working on Tim Bisson's code of the virtio blovk device driver.
I kept on testing the code, but I faced severals bugs:

When running a dd test, with small or big data to write on the virtio 
block device, the console/machine would usually freeze. (log messages [1])

       ---> When a request is not treated because there is no free 
place in the queue, it is placed in a vbb_queue and it tries again 
later. However, in the virtio_blk_execute function, when virtio_enqueue 
prep passed but virtio_enqueue_reserve failed, the request wasn't 
inserted again in the vbb_queue.
So I added some lines to perform this: l.241 in virtio-blk.c [2]

But it didn't solve the problem entirely. And it was linked with the 
second bug. Sometimes I had only the first one, sometimes only the 
second one, sometimes both.

Another part of the solution (I think) is that I was working on a virtio 
disk which was formated in hammer FS. But maybe it was too small. I had 
a problem on my kvm hard disk  (df / told me it was full, but a du 
command indicated that I occupated only 6% of the total capacity - a 
"hammer -h cleanup" command saved me. )
So I did my tests again on a virtio block device formated in UFS, and it 
seems to work better. I will try again with a bigger hammer partition.

The block device wouldn't umount correctly and/or the virtio-blk module 
wouldn't unload. The only way to solve the problem was rebooting.
I activated the debug mode in the code, but I had no access to any log 
messages related to these problems because the console/machine was 
frozen before the key  moment.

       --->The problem was due to the fact that in the 
virtio_blk_detatch() function, vq->vq_entries was freed twice: once by 
the call of the virtio_free_entry and once by a direct call of kfree in 
virtio_blk_detach(). [3]

Meanwhile, I began to work on the virtio network device driver. I wrote 
the probe/attach/detach functions (not tested yet) [4]. It gave me some 
ideas for debugging the block device driver when I didn't know where to 
I looked carefully at the NetBSD code. Some parts of the code are quite 
"dirty" (especially the virtio_alloc_mems() function).


[1] github.com/arroway/virtio_DragonFlyBSD/blob/dev-block/kldload_logs.txt
[4] github.com/arroway/virtio_DragonFlyBSD/blob/dev-net/net/virtio-net.c


More information about the Kernel mailing list