Re: [PATCH] iommu/arm-smmu-v3-sva: Enable Hardware Access and Hardware Dirty bits

[Pranjal Shrivastava <praan@google.com>]

On Wed, May 13, 2026 at 12:42:47PM +0100, Will Deacon wrote:
> On Mon, May 11, 2026 at 01:22:23PM +0000, Pranjal Shrivastava wrote:
> > On Sat, May 09, 2026 at 12:56:57AM -0700, Nicolin Chen wrote:
> > > On Fri, May 08, 2026 at 03:24:32PM +0100, Robin Murphy wrote:
> > > > On 2026-05-08 2:57 pm, Pranjal Shrivastava wrote:
> > > > > I see, so IIUC, you mean if IS_ENABLED(CONFIG_ARM64_HW_AFDBM) but CPU
> > > > > doesn't enable HTTU, it is perfectly safe to let the SMMU do HTT updates,
> > > > > Since the fault handlers are already expecting HW-triggered updates?
> > > > > 
> > > > > Which means our check would be something like:
> > > > > 
> > > > >     if (IS_ENABLED(CONFIG_ARM64_HW_AFDBM) {
> > > > >     	if (smmu->features & FEAT_HA)
> > > > > 	 ...
> > > > >     }
> > > > > 
> > > > > instead of cpu_has_hw_af()?
> > > > 
> > > > Hmm, looking closer, cpu_has_hw_af() is the thing which actually influences
> > > > mm behaviour (via arch_has_hw_pte_young and arch_wants_old_prefaulted_pte),
> > > > and that can still be false at runtime if ARM64_HW_AFDBM is enabled but any
> > > > CPU doesn't support HAFDBS, so perhaps you were right the first time :)
> > > 
> > > IIUIC, v2 should be:
> > > 
> > > +		/*
> > > +		 * Enable Hardware Access and Dirty updates (DBM) if supported by
> > > +		 * both the SMMU and the CPU. It is unsafe to enable SMMU's HTTU,
> > > +		 * if the CPU does not support it as it bypasses mm page aging.
> > > +		 */
> > > +		if (cpu_has_hw_af()) {
> > 
> > Ack, yes. IMO, this is the correct system-wide gate.
> 
> Hmm, I'm not so sure :/
> 
> cpu_has_hw_af() doesn't take into account CPUs with broken DBM and, in
> fact, ID_AA64MMFR1_EL1.HAFDBS allows support for AF to be advertised
> without support for DBM.
> 
> Having said that, I don't understand why we need to care about the CPU
> support. The comment above states:
> 
>   "It is unsafe to enable SMMU's HTTU, if the CPU does not support it as
>    it bypasses mm page aging."
> 
> but I don't understand what that "bypassing" means. vmscan should still
> pick up the correct state from the page-table, so what's the problem?

I agree that for the Access Flag (AF), vmscan would eventually see the 
bit in the table. However, I’m concerned about Hardware Dirty (HD/DBM).
I know the vmscan might eventually get to it.. but here's my worry:

IIUC, in arm64 the dirty state of a page is tracked through a specific 
protocol using the PTE_RDONLY and PTE_WRITE (DBM) bits. A shared writable
page is initially mapped with both bits set (_PAGE_SHARED [1])

It also seems to be documented in arch/arm64/include/asm/pgtable.h [2]:

/*
 * PTE bits configuration in the presence of hardware Dirty Bit Management
 * (PTE_WRITE == PTE_DBM):
 *
 * Dirty  Writable | PTE_RDONLY  PTE_WRITE  PTE_DIRTY (sw)
 *   0      0      |   1           0          0
 *   0      1      |   1           1          0
 *   1      0      |   1           0          1
 *   1      1      |   0           1          x
 *
 * When hardware DBM is not present, the software PTE_DIRTY bit is updated via
 * the page fault mechanism. Checking the dirty status of a pte becomes:
 *
 *   PTE_DIRTY || (PTE_WRITE && !PTE_RDONLY)
 */

Thus, if the CPU does not support/enable Hardware Dirty management
(TCR_EL1.HD == 0), it is forced to trigger a Permission Fault on the 1st
write because PTE_RDONLY is 1. The fault allows the kernel to call 
folio_mark_dirty() [3]

If we enable SMMU HD independently in the Context Descriptor, the SMMU
will see a write and silently clear PTE_RDONLY in the hardware table.
When the CPU later accesses the page, it sees PTE_RDONLY == 0 and 
proceeds without ever faulting.

Now, if we're work on an SVA page, with only SMMU supporting HTTU. A DMA
writes to the page and the process (CPU) calls fsync(). IIUC, it performs
a lookup in the Page Cache specifically for folios tagged as DIRTY.
Since, vmscan didn't run yet, this could potentally drop the writes..

Thanks,
Praan

[1] https://elixir.bootlin.com/linux/v7.1-rc3/source/arch/arm64/include/asm/pgtable-prot.h#L61
[2] https://elixir.bootlin.com/linux/v7.1-rc3/source/arch/arm64/include/asm/pgtable.h#L390
[3] https://elixir.bootlin.com/linux/v7.1-rc3/source/mm/memory.c#L3698