Re: [RFC] virtio-villain: Guest fault injection for VMM robustness

["Daniel P. Berrangé" <berrange@redhat.com>]

On Mon, Jul 06, 2026 at 09:22:12PM +0200, Anatol Belski wrote:
> 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 ?

snip

> 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.

We appreciate the intent not to flood projects ! Feel free to
drip-feed issues to us, a handful at a time though over days
or weeks if there will be alot to process.

We recently switched our security disclosure process over to using
our regular GitLab issue tracker, so would prefer any bugs to be
filed there, rather than emailing people directly:

  https://www.qemu.org/contribute/security-process/

This gives us resilience if individual manitainers are offline or
over-burdened by other work.

If it has security implications just select the "confidential"
tick box when filing. We can easily make it public if we decide
it is not a security issue during triage.

> > 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.

We also have tests/functional/ in QEMU where we boot real guest OS
disk images and/or kernel/initrd pairs. The minimal initramfs
approach would probably fit in nicely with that, and indeed I have
long wanted us to replace some of our full-fat disk images with
minimal self contained initramfs images to speed up smoke testing.

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|