mirror of https://github.com/xemu-project/xemu.git
2791490de1
The loop isn't setting the values for the last element. Every other
element is being initialized with addr = 0, flags = VRING_DESC_F_NEXT
and next = i + 1. The last elem is never touched.
This became a problem when enabling a RISC-V 'virt' libqos machine in
the 'indirect' test of virti-blk-test.c. The 'flags' for the last
element will end up being an odd number (since we didn't touch it).
Being an odd number it will be mistaken by VRING_DESC_F_NEXT, which
happens to be 1.
Deep into hw/virt/virtio.c, in virtqueue_split_pop(), into
virtqueue_split_read_next_desc(), a check for VRING_DESC_F_NEXT will be
made to see if we're supposed to chain. The code will keep up chaining
in the last element because the uninitialized value happens to be odd.
We'll error out right after that because desc->next (which is also
uninitialized) will be >= max. A VIRTQUEUE_READ_DESC_ERROR will be
returned, with an error message like this in the stderr:
qemu-system-riscv64: Desc next is 49391
Since we never returned, we'll end up timing out at qvirtio_wait_used_elem():
ERROR:../tests/qtest/libqos/virtio.c:236:qvirtio_wait_used_elem:
assertion failed: (g_get_monotonic_time() - start_time <= timeout_us)
The root cause is using uninitialized values from guest_alloc() in
qvring_indirect_desc_setup(). There's no guarantee that the memory pages
retrieved will be zeroed, so we can't make assumptions. In fact, commit
|
||
|---|---|---|
| .. | ||
| avocado | ||
| bench | ||
| data | ||
| decode | ||
| docker | ||
| fp | ||
| guest-debug | ||
| image-fuzzer | ||
| include | ||
| keys | ||
| lcitool | ||
| migration | ||
| multiboot | ||
| perf/block/qcow2 | ||
| plugin | ||
| qapi-schema | ||
| qemu-iotests | ||
| qtest | ||
| rocker | ||
| tcg | ||
| tsan | ||
| uefi-test-tools | ||
| unit | ||
| vm | ||
| vmstate-static-checker-data | ||
| Makefile.include | ||
| dbus-vmstate-daemon.sh | ||
| meson.build | ||
| test-qht-par.c | ||
| vhost-user-bridge.c | ||