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

Leonardo Bras
2026-04-30T13:29:56Z

On Thu, Apr 30, 2026 at 02:14:22PM +0100, Marc Zyngier wrote:
> On Thu, 30 Apr 2026 12:14:04 +0100,
> Leonardo Bras <leo.bras@arm.com> wrote:
>
> [...]
>
> I haven't had a chance to look at any of this yet, but just on these
> points:
>
> > b - checkpatch.pl keeps bothering me to add an entry in MAINTAINERS file,
> > and I like the idea of maintaining this. Is there any rule or
> > common sense on this? Should I add this entry, or should I leave it
> > in the arch/arm64/kvm/ general rule?
>
> No specific entry in MAINTAINERS required (or wanted). This falls into
> the normal KVM/arm64 maintenance. And don't worry, we know where to
> find you when it will come to fixing this stuff.
>

Got it

> > c - There are some trace_prink() I have left in the code, as they could
> > be helpful to check when HACDBS is not performing as well as it
> > should. Should I introduce a tracepoint instead? or just ignore it?
> > (it's triggered on HACDBS error, but as it falls back to software in
> > that case, it should not impact correctness, only performance).
>
> Debug infrastructure should be preferably *removed* altogether.
> trace_printk() is definitely a big no-no.
>

Will remove it then

> > d - In __kvm_arch_dirty_log_clear() there is no way to predict how long
> > should be the buffer, so I used 1x PAGE_SIZE, and when it gets full
> > it's cleaned and reused. Should I let users configure that over a
> > parameter, or is it overthinking?
>
> How long is a piece of string? We can't know that. A single page feels
> very small in the 4kB case, and letting userspace define the size of
> that buffer seems a likely requirement.
>

Ok, as a KVM parameter, or as a compile-time option?

> >
> > Kernel v7.0.0 + this patchset builds properly, passing both kvm selftests
> > for dirty-bit tracking[2], on HW HACDBS enabled or disabled.
>
> I have absolutely no trust in these tests.
>
> Have you enabled a VMM to make use of these APIs, and actively
> migrated running guests? That's the level of testing I'd like to see,
> as the selftests are not what people run in production...
>

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.

Do you prefer me to test on any specific scenario, or does whatever qemu
uses as a default parameter work well enough?

Thanks!
Leo