Hi all,
Following up on the previous discussion in this thread [1], I'm submitting a
cleaned-up version of the patch to improve error messages in
virtio_init_region_cache() when virtqueue ring mapping fails.
This version introduces a helper (virtio_get_pretty_dev_name()) that returns
either:
- the device ID, if explicitly set by the user (e.g. -device ...,id=foo)
- or the QOM path from qdev_get_dev_path(dev) otherwise
This improves the clarity of error messages, especially when debugging
misconfigured guests or setups with multiple virtio devices.
## Example 1: PCI device (fallback to QOM path returns PCI ID)
~/qemu/build$ ./qemu-system-x86_64 \
-enable-kvm \
-m 512 \
-drive if=virtio,file=/tmp/some.img,format=raw
qemu-system-x86_64: Failed to map descriptor ring for device 0000:00:04.0:
invalid guest physical address or corrupted queue setup
## Example 2: Non-PCI virtio-mmio device (QOM path fallback)
~/qemu/build$ ./qemu-system-aarch64 -M virt -cpu cortex-a57 -m 512 -nographic \
-append "console=ttyAMA0" \
-drive if=none,file=/tmp/some.img,format=raw,id=hd0 \
-device virtio-blk-device,drive=hd0 \
-kernel /tmp/vmlinuz-5.15.0-qcomlt-arm64
qemu-system-aarch64: Failed to map descriptor ring for device
virtio-mmio@000000000a003e00: invalid guest physical address or corrupted queue
setup\
## Example 3: Explicit device ID (dev->id path)
~/qemu/build$ ./qemu-system-aarch64 -M virt -cpu cortex-a57 -m 512 -nographic \
-append "console=ttyAMA0" \
-drive if=none,file=/tmp/some.img,format=raw,id=hd0 \
-device virtio-blk-device,drive=hd0,id=foo \
-kernel /tmp/vmlinuz-5.15.0-qcomlt-arm64
qemu-system-aarch64: Failed to map available ring for device foo: possible
queue misconfiguration or overlapping memory region
As discussed, I considered using qdev_get_human_name() but it often returns
opaque paths like
/machine/peripheral-anon/device[0]/virtio-backend
Which are less informative in user-facing logs compared to PCI IDs or
user-specified names.
The messages have been adjusted to be more descriptive and scoped to improving
this specific area of diagnostics. I hope this aligns with the direction
discussed — but of course, I’m open to further suggestions if something still
feels off.
Thank you for your time and consideration.
Best regards,
Alessandro Ratti
[1]:
https://lore.kernel.org/qemu-devel/20250915100701.224156-1-alessan...@0x65c.net/
