public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Leonardo Bras <leo.bras@arm.com>
Cc: "Catalin Marinas" <catalin.marinas@arm.com>,
	"Will Deacon" <will@kernel.org>,
	"Oliver Upton" <oupton@kernel.org>,
	"Joey Gouly" <joey.gouly@arm.com>,
	"Suzuki K Poulose" <suzuki.poulose@arm.com>,
	"Zenghui Yu" <yuzenghui@huawei.com>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	"Len Brown" <lenb@kernel.org>,
	"Saket Dumbre" <saket.dumbre@intel.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Chengwen Feng" <fengchengwen@huawei.com>,
	"Jonathan Cameron" <jic23@kernel.org>,
	"Kees Cook" <kees@kernel.org>,
	"Mikołaj Lenczewski" <miko.lenczewski@arm.com>,
	"Ryan Roberts" <ryan.roberts@arm.com>,
	"Yang Shi" <yang@os.amperecomputing.com>,
	"Thomas Huth" <thuth@redhat.com>,
	mrigendrachaubey <mrigendra.chaubey@gmail.com>,
	"Yeoreum Yun" <yeoreum.yun@arm.com>,
	"Mark Brown" <broonie@kernel.org>,
	"Kevin Brodsky" <kevin.brodsky@arm.com>,
	"James Clark" <james.clark@linaro.org>,
	"Ard Biesheuvel" <ardb@kernel.org>,
	"Fuad Tabba" <tabba@google.com>,
	"Raghavendra Rao Ananta" <rananta@google.com>,
	"Nathan Chancellor" <nathan@kernel.org>,
	"Vincent Donnefort" <vdonnefort@google.com>,
	"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
	"Sascha Bischoff" <Sascha.Bischoff@arm.com>,
	"Anshuman Khandual" <anshuman.khandual@arm.com>,
	"Tian Zheng" <zhengtian10@huawei.com>,
	"Wei-Lin Chang" <weilin.chang@arm.com>,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
	linux-acpi@vger.kernel.org, acpica-devel@lists.linux.dev,
	kvm@vger.kernel.org
Subject: Re: [PATCH v1 00/12] KVM Dirty-bit cleaning accelerator (HACDBS)
Date: Thu, 30 Apr 2026 14:14:22 +0100	[thread overview]
Message-ID: <86bjf0zj2p.wl-maz@kernel.org> (raw)
In-Reply-To: <20260430111424.3479613-2-leo.bras@arm.com>

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.

  parent reply	other threads:[~2026-04-30 13:14 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-30 11:14 [PATCH v1 00/12] KVM Dirty-bit cleaning accelerator (HACDBS) Leonardo Bras
2026-04-30 11:14 ` [PATCH v1 01/12] KVM: arm64: Enable eager hugepage splitting if HDBSS is available Leonardo Bras
2026-04-30 11:14 ` [PATCH v1 02/12] KVM: arm64: HDBSS bits Leonardo Bras
2026-04-30 11:14 ` [PATCH v1 03/12] arm64/cpufeature: Add system-wide FEAT_HACDBS detection Leonardo Bras
2026-04-30 11:14 ` [PATCH v1 04/12] arm64/sysreg: Add HACDBS consumer and base registers Leonardo Bras
2026-04-30 11:14 ` [PATCH v1 05/12] KVM: arm64: Detect (via ACPI) and initialize HACDBSIRQ Leonardo Bras
2026-04-30 11:14 ` [PATCH v1 06/12] KVM: arm64: dirty_bit: Add base FEAT_HACDBS cleaning routine Leonardo Bras
2026-04-30 11:14 ` [PATCH v1 07/12] kvm: Add arch-generic interface for hw-accelerated dirty-bitmap cleaning Leonardo Bras
2026-04-30 11:14 ` [PATCH v1 08/12] KVM: arm64: Add hardware-accelerated dirty-bitmap cleaning routine Leonardo Bras
2026-04-30 11:14 ` [PATCH v1 09/12] kvm/dirty_ring: Introduce get_memslot and move helpers to header Leonardo Bras
2026-04-30 11:14 ` [PATCH v1 10/12] kvm/dirty_ring: Add arch-generic interface for hw-accelerated dirty-ring cleaning Leonardo Bras
2026-04-30 11:14 ` [PATCH v1 11/12] KVM: arm64: Add hardware-accelerated dirty-ring cleaning routine Leonardo Bras
2026-04-30 11:14 ` [PATCH v1 12/12] KVM: arm64: Enable KVM_HW_DIRTY_BIT Leonardo Bras
2026-04-30 13:14 ` Marc Zyngier [this message]
2026-04-30 13:29   ` [PATCH v1 00/12] KVM Dirty-bit cleaning accelerator (HACDBS) Leonardo Bras
2026-04-30 14:51     ` Marc Zyngier
2026-04-30 15:35       ` Leonardo Bras
2026-05-01  2:11       ` Mark Brown

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=86bjf0zj2p.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=Sascha.Bischoff@arm.com \
    --cc=acpica-devel@lists.linux.dev \
    --cc=anshuman.khandual@arm.com \
    --cc=ardb@kernel.org \
    --cc=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=fengchengwen@huawei.com \
    --cc=james.clark@linaro.org \
    --cc=jic23@kernel.org \
    --cc=joey.gouly@arm.com \
    --cc=kees@kernel.org \
    --cc=kevin.brodsky@arm.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.linux.dev \
    --cc=lenb@kernel.org \
    --cc=leo.bras@arm.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lpieralisi@kernel.org \
    --cc=miko.lenczewski@arm.com \
    --cc=mrigendra.chaubey@gmail.com \
    --cc=nathan@kernel.org \
    --cc=oupton@kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=rafael@kernel.org \
    --cc=rananta@google.com \
    --cc=ryan.roberts@arm.com \
    --cc=saket.dumbre@intel.com \
    --cc=suzuki.poulose@arm.com \
    --cc=tabba@google.com \
    --cc=thuth@redhat.com \
    --cc=vdonnefort@google.com \
    --cc=weilin.chang@arm.com \
    --cc=will@kernel.org \
    --cc=yang@os.amperecomputing.com \
    --cc=yeoreum.yun@arm.com \
    --cc=yuzenghui@huawei.com \
    --cc=zhengtian10@huawei.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox