about virtio driver porting from FreeBSD

Stéphanie Ouillon stephanie at minet.net
Tue Mar 22 11:57:27 PDT 2011


Hello,

thank you for your answer, I'm writing my application with the 
information provided in some other mail sent by Justin Sherill.
Then will I have to send it on this mailing list in advance ?

Le 21/03/11 16:19, Tim Bisson a écrit :
On 3/20/11 2:28 PM, Stéphanie Ouillon wrote:
Hello,

I come with some questions after I worked on virtio drivers during 
the week. The answers will help me to elaborate my timeline for the 
gsoc application :)

_1. Virtio Network Driver_

I solved the problem I discussed with Pratyush Kshirsagar about the 
loading of virtio.ko and I was able to check that the dmesg message 
was okay thanks to his help.
( I am still under Virtualbox, I set networks settings to virtio-net, 
bridge on the ethernet interface )
Here is the result of dmseg ( with some additional kprintf messages )  :

We enter virtio_probe()
    virtio_probe 4096
    Device 4096 is okay
      virtiobus0 port 0xd020-0XD03f irq 10 at device 3.0 on pci0
    We enter virtio_attach()
    Virtio Network Device (rev 0x00) 0xc2aa52f8
    Virtio Type: 1
    Network dev child added
    We enter virtio_probe()
    virtio_probe 51966
    We enter virtio_probe()
    virtio_probe 9237
    We enter virtio_probe()
    virtio_probe 28947
So a virtio network device was found.

However, I face some problems with virtio-net when loading the module 
virtio-net.ko ( the child driver? ):
        - it tells me the module loads correctly but,
        - when I add some kprintf debug for dmseg, I can see that 
there are no calls to virtio_net_probe()
This is because of how I've set the drivers up. If you look at 
attach() in virtio.c, you'll see I end up doing a device_add_child() 
based on the type of device. When you then load the virtio-net driver, 
virtio_net_attach() should be called. This probably isn't the right 
way to do things, but it's how I got things working.

        - no network interface seems to be created, and I don't see 
which function in virtio-net.c creates it. I                 looked 
at the NetBSD code, if I understood it rightly, it uses ifnet to 
create the network interface with             the following functions 
: vioif-init(), vioif_stop(), etc ?
        - and to be sure I have no network, when I try to ping 
something, I get a "no route to host" message,                 and 
when I want to set a default route, I get a "network unreachable"
Right, it's only the skeleton of a driver. The virtio-net driver still 
needs to hook into the virtio APIS (like virtio-blk) and create a 
networking interface. Right now all it does it negotiate features with 
the backend.

I saw in some messages in the mailing list that some tests have been 
done by Tim Bisson 
(http://leaf.dragonflybsd.org/mailarchive/kernel/2011-01/msg00053.html). 
Was it realized with the code you gave me ?
No, that was code I ported from the non-BSD licensed FreeBSD virtio code.

_2. Ballooning and Block Device Drivers_

At the moment, I run DragonFly BSD under VirtualBox... which is not 
nice :/
There are no memory ballooning available on 32-bits machines ( I've 
got an 32-bits machine, a mac, so I don't have kvm anymore ) :( ) and 
no virtio block drivers at all for VirtualBox.
So it seems that I'll have to run DragonFly BSD under Qemu to run 
code on my computer. However, as the project aims at implementing 
virtio drivers to run DragonFly BSD under kvm, I also plan to install 
some virtual machines under kvm on a server I have access to.

Block device driver has been ported from NetBSD, and it seems to have 
been tested ( http://gitorious.org/virtio-drivers/pages/Home )?
Yes

And ballooning driver still remains to be ported from NetBSD. I read 
that Minoura's NetBSD code was checked on NetBSD before porting. Was 
it done for each driver ( including ballooning ) ?
Yes they work.

_
3. Changes to the kernel _
According to these messages ( 
http://leaf.dragonflybsd.org/mailarchive/kernel/2011-01/msg00046.html 
), the virtio net driver required some changes to the kernel ( adding 
kern/subr_sglist.c and making the probe interface public ). Why was 
it necessary ? Also, were some changes required for the block device 
driver ?
That was for the non-BSD licensed FreeBSD virtio-net driver. That 
driver used sglists to package the virtio header, payload, and length. 
The NetBSD drivers don't use sglists.

_4. Performance tests ( not really a question :) )_

As I understand it, tests will have to be done in order to compare 
performances with and without virtio, for each driver ( to be sure 
virtio is doing its job :) ).

Thank you !

Stéphanie Ouillon








More information about the Kernel mailing list