Re: about virtio driver porting from FreeBSD

[Tim Bisson <bissont@xxxxxxx>]

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