Re: [PATCH v1 00/12] KVM Dirty-bit cleaning accelerator (HACDBS)

Mark Brown <[email protected]> Fri, 1 May 2026 11:11:14 +0900

Newsgroups	dev.linux.lists.acpica-devel,dev.linux.lists.kvmarm,org.infradead.lists.linux-arm-kernel,org.kernel.vger.kvm,org.kernel.vger.linux-acpi,org.kernel.vger.linux-kernel
Message-ID	<[email protected]>

On Thu, Apr 30, 2026 at 03:51:20PM +0100, Marc Zyngier wrote:
> Leonardo Bras <[email protected]> wrote:

> > There is no enablement needed on VMM side.
> > Yes, I have created a VM on upstream qemu with --enable-kvm and migrated it 
> > on the same host. (Inside a model)

> > That was the first test I used, but then I found out that kvm selftests 
> > stress up multiple scenarios in an easier way.

> Except when they don't. In my experience, the selftests are only there
> to give the CI people the fuzzy feeling that they are doing something
> useful. I have a collection of examples indicating that what these
> things test is not representative of the bugs we have in KVM.

There's a bit of a circular thing there - if things are working well
then the selftests really shouldn't be representitive of the problems
that turn up since people ought to have seen any issues they show during
development.  If you could share your list that'd be helpful.

TBH the various stress style tests like the dirty bit ones in the KVM
selftests are actually a bit of a pain for CI IME.  Since they all
control their runtimes by iteration counts rather than time there's
scaling issues, the performance is such that on lower end systems
they're often on the edge of generating timeouts leading to unstable
results.  They also interact so poorly with the fast models that the run
time blows up spectacularly which is it's own problem trying to run
them, that's partly on the model side of course.  These performance
and/or stress tests really aren't idiomatic for kselftest so there's
always going to be some tension with trying to run them in that
framework.

signature.asc (application/pgp-signature, 488 B)