DragonFly BSD
DragonFly kernel List (threaded) for 2011-03
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: about virtio driver porting from FreeBSD


From: Stéphanie Ouillon <stephanie@xxxxxxxxx>
Date: Tue, 22 Mar 2011 19:53:42 +0100

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






[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]