getting a IoError but no clue what it means or how to fix

[walksanatora]

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

[walksanatora]

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

[walksanatora]

I have no clue what I am doing wrong and #os-dev is not helping

[qwandor]

Where is that log line coming from? Have you tried attaching a debugger to see where it is hanging?

[walksanatora]

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

[walksanatora]

[stderr.txt]
the full stderr

[walksanatora]

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

[qwandor]

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.

[walksanatora]

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

[walksanatora]

but still no clue why stdio stops working

[walksanatora]

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

[qwandor]

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.