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
>