Re: [PATCH v4 3/6] KVM: arm64: Add auto DBM support for hardware dirty tracking

From: Oliver Upton

Date: Thu Jul 16 2026 - 03:39:30 EST


Hi Tian,

On Thu, Jul 09, 2026 at 06:40:23PM +0800, Tian Zheng wrote:
> - if (prot & KVM_PGTABLE_PROT_W)
> + if (prot & KVM_PGTABLE_PROT_W) {
> set |= KVM_PTE_LEAF_ATTR_LO_S2_S2AP_W;
>
> + /*
> + * No DEVICE filter needed here: relax_perms is only called
> + * on FSC_PERM faults. Device pages always get full RW from
> + * initial mapping and are never write-protected during
> + * migration, so they never trigger a permission fault.
> + */
> + if (pgt->flags & KVM_PGTABLE_S2_DBM)
> + set |= KVM_PTE_LEAF_ATTR_HI_S2_DBM;
> + } else {
> + /*
> + * Clear DBM on W→RO downgrade to prevent hardware from
> + * silently upgrading RO+DBM back to W+dirty, which would
> + * bypass KVM's write tracking and cause data corruption.
> + */
> + clr |= KVM_PTE_LEAF_ATTR_HI_S2_DBM;
> + }
> +

This block makes it pretty evident that the DBM bit really *is* the
write permission bit. I'd much rather we introduce the concept of dirty
state to the page table library and migrate the abstract write
permission to the DBM field, even if we don't have FEAT_HAFDBS.

That way everything 'just works' from outside the page-table library:
write-protecting hugepages would have the effect of clearing DBM and we
can separately reap dirty state from page descriptors.

If/when the architecture forces FEAT_S2PIE upon us we will need to make
this change anyway since dirty state management is unconditional and
handled separately from the actual permissions.

Thanks,
Oliver