From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Anatol Belski <anbelski@linux.microsoft.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [RFC] virtio-villain: Guest fault injection for VMM robustness
Date: Wed, 8 Jul 2026 09:09:42 +0100 [thread overview]
Message-ID: <ak4Fxt989xkWfgwD@redhat.com> (raw)
In-Reply-To: <861020196095d6d91a83b878a1ed744b2824d159.camel@linux.microsoft.com>
On Tue, Jul 07, 2026 at 11:09:12PM +0200, Anatol Belski wrote:
> On Tue, 2026-07-07 at 11:39 +0100, Daniel P. Berrangé wrote:
>
> > 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/
>
> Perfect, that makes it easy. I will file on the GitLab tracker and
> send them in small batches over the next couple of weeks rather than
> all at once. For the ones with a host side impact, a guest triggered
> hang or use after free, I will tick the confidential box and let
> triage decide whether it stays that way.
>
>
> > 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.
>
> That sounds like a clean fit. The harness already boots a kernel plus
> a tiny initramfs with a single static init and no full OS, so it
> should slot into tests/functional/ with little friction. Each test
> finishes in under a second when passing, since there is no full VM
> boot involved, which makes it suitable for smoke testing too. Would
> it be useful to have these wired in there directly, or is there a
> different shape that would work better for you?
Yes, I think it'd be interesting to try to fit them directly into a
functional test script. I guess having the virtio-villain repo as a
git submodule would probably be the way to go to access the individual
tests to build the initramfs.
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 :|
next prev parent reply other threads:[~2026-07-08 8:10 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-04 13:37 [RFC] virtio-villain: Guest fault injection for VMM robustness Anatol Belski
2026-07-06 8:29 ` Daniel P. Berrangé
2026-07-06 19:22 ` Anatol Belski
2026-07-07 10:39 ` Daniel P. Berrangé
2026-07-07 21:09 ` Anatol Belski
2026-07-08 8:09 ` Daniel P. Berrangé [this message]
2026-07-08 18:25 ` Anatol Belski
2026-07-09 7:17 ` Daniel P. Berrangé
2026-07-09 10:02 ` Anatol Belski
2026-07-10 12:52 ` Matias Ezequiel Vara Larsen
2026-07-10 22:27 ` Anatol Belski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ak4Fxt989xkWfgwD@redhat.com \
--to=berrange@redhat.com \
--cc=anbelski@linux.microsoft.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.