Hi Daniel, On Mon, 2026-07-06 at 09:29 +0100, Daniel P. Berrangé wrote: > On Sat, Jul 04, 2026 at 03:37:21PM +0200, Anatol Belski wrote: > > > The README only lists cloud hypervisor bugs. Did you file any for > QEMU yet ?
Thanks for checking. Yeah, the README only has the Cloud Hypervisor fixes so far, those being the ones already merged. The QEMU ones are not filed yet, they are still just reproducer tests in the harness. There are several findings, though. As one example, a block read whose data descriptor points at the device own MMIO BAR deadlocks the VM under the BQL, so a single descriptor freezes the whole thing. https://github.com/weltling/virtio-villain/blob/main/tests/vring/t0063_desc_addr_pci_bar.c I have been reaching out to a few QEMU maintainers individually first, to confirm these are ordinary robustness bugs and not security sensitive before anything goes public. I am being careful because automated and AI generated reports are flooding projects right now, and I did not want to add noise or mishandle something sensitive. > > If this is finding bugs in QEMU this test harness sounds like the > kind > of thing we ought to have integrated in QEMU's meson test suite such > that it runs in CI to prevent regressions. > Makes sense. I have been exercising QEMU regularly anyway, since it is the de facto standard to compare against, so wiring the harness into the QEMU test setup to catch regressions is a natural fit. One note on shape. qtest drives a device from outside the guest, poking its registers over a socket with no guest code running. virtio-villain works the other way around, it boots a tiny init into an initramfs, with no full OS, and that guest drives the device as real guest code. So it stays lightweight, just a booted guest rather than an external driver. I think that is worth exploring. The harness is public, so it is there to build on, and I am glad to help work out how it could fit. Thanks Anatol
