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
>>
>