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

[Leonardo Bras <leo.bras@arm.com>]

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