[gsoc] Virtio block device driver
Stéphanie Ouillon
stephanie at minet.net
Tue May 31 13:07:58 PDT 2011
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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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
More information about the Kernel
mailing list