[gsoc] Virtio block device driver

[Stéphanie Ouillon <stephanie@xxxxxxxxx>]

Hello,

I modified some parts of the code of the virtio block device driver that has been already ported from NetBSD.
The code is available here : github.com/arroway/virtio_DragonFlyBSD

The initially ported block device driver is available in the block/ direectory : it was working on its own.
What I did is that I modified it so that it could work with a more general interface, virtio.c

First the virtio module is called, and it detects or not a virtio device. Then, according to the type of the virtio device ( here, a block device ), it calls the virtio_blk module.

I've got some problems to attach my virtio device with virtio_blk.

Here is what I did, as I told my mentor Pratyush  Kshirsagar :

Some functions were defined twice : in virtio_blk.c and in virtio.c. In virtio.c, their prototypes accepted a virtio_softc * structure, but in virtio_blk.c, they wanted a virtio_blk_softc * structure.
Now, I only use the functions in virtio.c ( I deleted the corresponding functions in virtio_blk.c to keep ony the functions that were specific to the block device ).

 So I changed the definition of virtio_blk_softc * structure in virtio_blk.c. Now it looks like this :
(like in the netbsd code)

struct virtio_blk_softc {

    device_t sc_dev;

    struct virtio_softc *sc_virtio;
    struct virtqueue sc_vq[1];

    struct virtio_blk_req    *sc_reqs;
    int sc_readonly;
    uint32_t    sc_features;
    int     maxxfersize;

    //added : what for ?
    bus_dma_segment_t    sc_reqs_segs[1];
    //I don't use it at the moment ( virtio_blk_attach() )
    kmutex_t    sc_lock;

    // Block stuff : for testing with devstat
    cdev_t cdev;
    struct devstat stats;
    struct disk disk;

};



Then, the main change in the initial code is that I use the virtio_softc component of the virtio_blk_softc structure instead of virtio_blk_softc when I do operations on the queue.


When loading modules :
I only have to load the virtio_blk module :

# kldload -v ./virtio_blk.ko
Loaded ./virtio_blk.ko, id=10
# dmseg
virtio_probe 28947virtio_probe 4097virtiobus0 port 0xc300-0xc33f mem 0xf2060000-0xf2060fff irq 10 at device 5.0 on pci0
Virtio Block Device (rev. 0x00) 0xc2a857a8
Virtio Type: 2
Block dev child added
virtio_blk_probe product_id:47088
virtio_blk_probe product_id:22144
virtio_blk_probe product_id:22144
virtio_blk_probe product_id:22144
virtio_blk_probe product_id:22144

I can't load both the virtio and the virtio_blk modules :

# kldload -v ./virtio.ko
Loaded ./virtio.ko, id=8
# kldload -v ./virtio_blk.ko
kldload: can't load ./virtio_blk.ko: File exists
# dmesg
virtio_probe 28947virtio_probe 4097virtiobus0 port 0xc300-0xc33f mem 0xf2060000-0xf2060fff irq 10 at device 5.0 on pci0
Virtio Block Device (rev. 0x00) 0xc2a857a8
Virtio Type: 2
Block dev child added
interface virtiobus.0 already present in the KLD 'virtio.ko'!

The point is that I don't see where, in virtio_blk.c, it requires to define again virtiobus ?


As you can notice in the first dmesg, it calls the virtio_blk_probe function in virtio_blk.c, but not virtio_blk_attach().
Yet, I do have a virtio block device (below, in bold) :

# pciconf -l -v
hostb0@pci0:0:0:0:    class=0x060000 card=0x11001af4 chip=0x12378086 rev=0x02 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = '82440/1FX 440FX (Natoma) System Controller'
    class      = bridge
    subclass   = HOST-PCI
isab0@pci0:0:1:0:    class=0x060100 card=0x11001af4 chip=0x70008086 rev=0x00 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = '82371SB PIIX3 PCI-to-ISA Bridge (Triton II)'
    class      = bridge
    subclass   = PCI-ISA
atapci0@pci0:0:1:1:    class=0x010180 card=0x11001af4 chip=0x70108086 rev=0x00 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = '82371SB PIIX3 IDE Interface (Triton II)'
    class      = mass storage
    subclass   = ATA
uhci0@pci0:0:1:2:    class=0x0c0300 card=0x11001af4 chip=0x70208086 rev=0x01 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = '82371SB PIIX3 USB Host Controller (Triton II)'
    class      = serial bus
    subclass   = USB
none0@pci0:0:1:3:    class=0x068000 card=0x11001af4 chip=0x71138086 rev=0x03 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = '82371AB/EB/MB PIIX4/4E/4M Power Management Controller'
    class      = bridge
vgapci0@pci0:0:2:0:    class=0x030000 card=0x11001af4 chip=0x00b81013 rev=0x00 hdr=0x00
    vendor     = 'Cirrus Logic'
    device     = 'CL-GD5446 64-bit VisualMedia Accelerator'
    class      = display
    subclass   = VGA
re0@pci0:0:3:0:    class=0x020000 card=0x11001af4 chip=0x813910ec rev=0x20 hdr=0x00
    vendor     = 'Realtek Semiconductor'
    device     = 'RT8139 (A/B/C/810x/813x/C+) Fast Ethernet Adapter'
    class      = network
    subclass   = ethernet
re1@pci0:0:4:0:    class=0x020000 card=0x11001af4 chip=0x813910ec rev=0x20 hdr=0x00
    vendor     = 'Realtek Semiconductor'
    device     = 'RT8139 (A/B/C/810x/813x/C+) Fast Ethernet Adapter'
    class      = network
    subclass   = ethernet
virtiobus0@pci0:0:5:0:    class=0x010000 card=0x00021af4 chip=0x10011af4 rev=0x00 hdr=0x00
    vendor     = 'Red Hat, Inc'
    device     = 'Virtio block device'
    class      = mass storage
    subclass   = SCSI


I didn't mount the device, I guess it is acd0 ( I have one hard disk, one virtio disk, and one dvd driver). I can't mount it either (which is normal, since it doesn't support virtio type, yet).

# egrep 'ad[0-9]|cd[0-9]' /var/run/dmesg.boot
disk scheduler: set policy of ad0 to noop
ad0: 20480MB <QEMU HARDDISK 0.14.0> at ata0-master WDMA2
disk scheduler: set policy of acd0 to noop
acd0: CDROM <QEMU DVD-ROM/0.14.0> at ata1-master WDMA2
disk scheduler: set policy of cd0 to noop
cd0 at ata1 bus 0 target 0 lun 0
cd0: <QEMU QEMU DVD-ROM 0.14> Removable CD-ROM SCSI-0 device
cd0: 16.000MB/s transfers
cd0: cd present [287674 x 2048 byte records]
# mount /dev/acd0
mount: /dev/acd0: unknown special file or file system

So I'm still searching for where the problem is. Has anybody got a clue about it ?


--
Stéphanie