about virtio driver porting from FreeBSD

Tim Bisson bissont at mac.com
Mon Mar 21 08:22:52 PDT 2011


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