From: Marc Zyngier <maz@kernel.org>
To: Tian Zheng <zhengtian10@huawei.com>
Cc: Leonardo Bras <leo.bras@arm.com>, <oupton@kernel.org>,
<catalin.marinas@arm.com>, <will@kernel.org>,
<yuzenghui@huawei.com>, <wangzhou1@hisilicon.com>,
<yangjinqian1@huawei.com>, <caijian11@h-partners.com>,
<liuyonglong@huawei.com>, <yezhenyu2@huawei.com>,
<yubihong@huawei.com>, <linuxarm@huawei.com>,
<joey.gouly@arm.com>, <kvmarm@lists.linux.dev>,
<kvm@vger.kernel.org>, <linux-arm-kernel@lists.infradead.org>,
<linux-kernel@vger.kernel.org>, <seiden@linux.ibm.com>,
<suzuki.poulose@arm.com>
Subject: Re: [PATCH v4 3/6] KVM: arm64: Add auto DBM support for hardware dirty tracking
Date: Tue, 14 Jul 2026 08:23:26 +0100 [thread overview]
Message-ID: <86zezunifl.wl-maz@kernel.org> (raw)
In-Reply-To: <8f949334-3ce7-44f4-b6da-f08a4126affd@huawei.com>
On Tue, 14 Jul 2026 02:14:45 +0100,
Tian Zheng <zhengtian10@huawei.com> wrote:
>
>
> On 7/13/2026 7:17 PM, Leonardo Bras wrote:
> > On Thu, Jul 09, 2026 at 06:40:23PM +0800, Tian Zheng wrote:
> >> The DBM (Dirty Bit Modifier) attribute, introduced in ARMv8.1, enables
> >> hardware to automatically promote write-clean pages to write-dirty. This
> >> prevents the guest from being trapped in EL2 due to missing write
> >> permissions.
> >>
> >> In this design, DBM is controlled by the page-table level flag
> >> KVM_PGTABLE_S2_DBM rather than per-PTE software flags. DBM is
> >> automatically set for writable non-device pages when the page-table has
> >> KVM_PGTABLE_S2_DBM flag, which is determined at MMU init time based on
> >> hardware capability.
> >>
> >> The DBM bit is set in stage2_set_prot_attr() for initial mappings and
> >> hugepage splitting, and directly manipulated in
> >> kvm_pgtable_stage2_relax_perms() when removing write-protection. On
> >> W->RO downgrade, DBM is cleared to prevent hardware from silently
> >> upgrading RO+DBM back to W+dirty, which would bypass KVM's write
> >> tracking.
> >>
> >> kvm_pgtable_stage2_pte_prot() does not extract the DBM bit back into
> >> enum kvm_pgtable_prot because DBM is a page-table policy determined by
> >> pgt->flags, not a per-PTE property. Callers should check
> >> pgt->flags & KVM_PGTABLE_S2_DBM instead.
> >>
> >> This ensures DBM is consistently applied across all PTEs, including
> >> during hugepage splitting where child PTEs inherit DBM from the parent
> >> block entry via the pgt->flags mechanism.
> >>
> >> Safety: DBM bit is only interpreted by hardware when VTCR_EL2.HD=1.
> >> When HDBSS is not enabled (HD=0), ARM architecture guarantees hardware
> >> completely ignores DBM bit in PTEs.
> >>
> >> Co-developed-by: Eillon <yezhenyu2@huawei.com>
> >> Signed-off-by: Eillon <yezhenyu2@huawei.com>
> >> Co-developed-by: Leonardo Bras <leo.bras@arm.com>
> >> Signed-off-by: Leonardo Bras <leo.bras@arm.com>
> > Hello Tian,
> >
> > Have you added the above tags due to this patch being based on the below?
> > https://lore.kernel.org/all/20260629111820.1873540-2-leo.bras@arm.com/
> >
> > Thanks!
> > Leo
>
> Hi Leo,
>
>
> Yes, I added your Signed-off-by because the DBM-related code in this patch
You really can't do that. Only Leo can give his SoB, you can't forge
it yourself.
>
> is based on your implementation in:
>
> https://lore.kernel.org/all/20260629111820.1873540-2-leo.bras@arm.com/
Then take the patch as is, and add to it as a separate patch. Or work
out in private with Leo whether he's happy with a Co-dev. But never do
that unilaterally.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
next prev parent reply other threads:[~2026-07-14 7:23 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-09 10:40 [PATCH v4 0/6] Support the FEAT_HDBSS introduced in Armv9.5 Tian Zheng
2026-07-09 10:40 ` [PATCH v4 1/6] KVM: arm64: Enable eager hugepage splitting if HDBSS is available Tian Zheng
2026-07-09 11:03 ` sashiko-bot
2026-07-09 10:40 ` [PATCH v4 2/6] KVM: arm64: Add support for FEAT_HDBSS Tian Zheng
2026-07-09 11:00 ` sashiko-bot
2026-07-09 10:40 ` [PATCH v4 3/6] KVM: arm64: Add auto DBM support for hardware dirty tracking Tian Zheng
2026-07-09 11:14 ` sashiko-bot
2026-07-13 11:17 ` Leonardo Bras
2026-07-14 1:14 ` Tian Zheng
2026-07-14 7:23 ` Marc Zyngier [this message]
2026-07-14 7:44 ` Tian Zheng
2026-07-09 10:40 ` [PATCH v4 4/6] KVM: arm64: Add HDBSS per-vCPU buffer management Tian Zheng
2026-07-09 11:15 ` sashiko-bot
2026-07-13 13:39 ` Leonardo Bras
2026-07-14 7:15 ` Tian Zheng
2026-07-09 10:40 ` [PATCH v4 5/6] KVM: arm64: Add HDBSS fault handling and buffer flush Tian Zheng
2026-07-09 11:26 ` sashiko-bot
2026-07-13 14:06 ` Leonardo Bras
2026-07-14 7:38 ` Tian Zheng
2026-07-09 10:40 ` [PATCH v4 6/6] KVM: arm64: Add auto HDBSS enable/disable on dirty logging change Tian Zheng
2026-07-09 11:34 ` sashiko-bot
2026-07-13 14:50 ` Leonardo Bras
2026-07-13 10:31 ` [PATCH v4 0/6] Support the FEAT_HDBSS introduced in Armv9.5 Leonardo Bras
2026-07-13 16:27 ` Leonardo Bras
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=86zezunifl.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=caijian11@h-partners.com \
--cc=catalin.marinas@arm.com \
--cc=joey.gouly@arm.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.linux.dev \
--cc=leo.bras@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=liuyonglong@huawei.com \
--cc=oupton@kernel.org \
--cc=seiden@linux.ibm.com \
--cc=suzuki.poulose@arm.com \
--cc=wangzhou1@hisilicon.com \
--cc=will@kernel.org \
--cc=yangjinqian1@huawei.com \
--cc=yezhenyu2@huawei.com \
--cc=yubihong@huawei.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