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
