virtio-drivers
virtio-drivers copied to clipboard
getting a IoError but no clue what it means or how to fix
https://github.com/walksanatora/oc2kernel/blob/master/src/main.rs#L119-L136 is the virtio code but yet it always returns with a IO error you can see my qemu args in run.sh
switched to using the propper blocking command
but now (updated from 0.4.0 to 0.6.0) it hangs when i create the VirtioBlk using the mmio transport
and the last line is virtio_mmio_setting_irq virtio_mmio setting IRQ 1
I have no clue what I am doing wrong and #os-dev is not helping
Where is that log line coming from? Have you tried attaching a debugger to see where it is hanging?
it is the last line from qemu stderr (before it hangs*) with
qemu-system-riscv64 -kernel kernel.bin \
-machine virt \
-cpu rv64 \
-serial stdio \
-device virtio-blk-device,serial=deadbeef,drive=disk0 \
-global virtio-mmio.force-legacy=false \
-drive id=disk0,format=raw,if=none,file=disk0.img \
-trace virtio_mmio*
(specifically the -trace virtio_mmio*)
[stderr.txt] the full stderr
the last println!
being hit is https://github.com/walksanatora/oc2kernel/blob/7b16402b3b7035d4cd5eb5470ce117584090dca6/src/main.rs#L123
then it enters the VirtIOBlk setup, and i get a few more messages from log
Device features: BlkFeature(SEG_MAX | GEOMETRY | BLK_SIZE | FLUSH | TOPOLOGY | C
ONFIG_WCE | DISCARD | WRITE_ZEROES | RING_INDIRECT_DESC | RING_EVENT_IDX | VERSIO
N_1)
config: 0x10008100
found a block device of size 8192KB
2 calls to allocate DMA pages
alloc@0?1: 1000000000000000000000000000000000000000000000000000000000000000
2151837760 + (4096 * 0) = 2151837760
alloc@1?1: 1100000000000000000000000000000000000000000000000000000000000000
2151837760 + (4096 * 1) = 2151841856
and then hang... full combined log of stdout+stderr out.txt
Well the virtio_mmio_write_offset virtio_mmio_write offset 0x70 value 0xf
line suggests that it gets as far as transport.finish_init()
, and virtio_mmio_write_offset virtio_mmio_write offset 0x50 value 0x0
is notifying the device that there is an entry in the queue to process. It's weird that your log lines before that don't make it to the console though. I suggest stepping through it in a debugger to see where it actually gets stuck.
so you mean Uart is somehow dying? hmm (idk how to do debugging with qemu, lemme search it up) okay after using some basid GDB it is reaching the Temp end panic but it is not writing the disk wait... is the blockid base 0 ofc it is
but still no clue why stdio stops working
okay stdio started working again. but now i have to use PciTransport to interact with VirtIO console
but when I connect to it it always fails with Bar 4 not allocated
and i cant find any function to allocate the bar
Why do you need to use the PCI transport rather than MMIO?
If your bootloader doesn't allocate PCI BARs, you can see https://github.com/rcore-os/virtio-drivers/blob/master/examples/aarch64/src/main.rs#L394 for an example of how you might do it. There's nothing VirtIO-specific about it though, it's just standard PCI initialisation.