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

Marc Zyngier
2026-04-30T13:14:31Z

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.

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

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

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

Thanks,

M.

--
Without deviation from the norm, progress is not possible.