Re: [RFC PATCH 1/5] KVM: arm64: pgtables: Change write bit from S2AP_W to DBM

[Tian Zheng]

On 9/21/2026 10:15 PM, Leonardo Bras wrote:
> On Fri, Sep 18, 2026 at 05:39:17PM +0800, Tian Zheng wrote:
> > On 9/16/2026 7:22 PM, Leonardo Bras wrote:
> > > On Tue, Sep 15, 2026 at 05:37:15PM -0700, Oliver Upton wrote:
> > > > On Tue, Sep 15, 2026 at 06:12:45PM +0100, Leonardo Bras wrote:
> > > > > > Yes, the HW should ignore it. But we have also
> > > > > > seen quite a few broken designs in this area...
> > > > >
> > > > > I lack experience on what bad thing could happen. So I will expand on what
> > > > > I belive to understand up to here:
> > > > >
> > > > > - The PTE is in memory, so the DBM bit can be set regardless of being RES0
> > > > > - For SW pagetable walking, I don't think 'bit 51 == 0' is checked
> > > > > - For HW pagetable walking, maybe some faulty implementation may rely on
> > > > >     bit51 being RES0, and fault otherwise.
> > > > >
> > > > > If that's the case, then we would have to actually support both encodings,
> > > > > and only enable the new one if HAFDBS is available in the system.
> > > > >
> > > > > I just wonder how high are the chances to have such a broken design,
> > > > > or other broken designs did not come to my mind, and if we have to start
> > > > > with that multiple-encoding option.
> > > >
> > > > FWIW, the host stage-1 already uses the DBM bit unconditionally,
> > > > treating it as a software bit on implementations without HAFDBS.
> > > > Although given the quality of any garden variety Arm MMU I understand
> > > > where Marc is coming from.
> > > >
> > > > I don't think the HAFDBS enablement is complicated enough to be done in
> > > > a separate series without any meaningful users, nor would I really be
> > > > interested in taking it without, say, HDBSS.
> > > >
> > > > Can you please work with Tian to get a combined series out for this?
> > >
> > > Hi Oliver, thanks for reviewing!
> > >
> > > Sure, one of the reasons I sent like this is so Tian could use it as a base
> > > for his next version.
> >
> > Hi Oliver, Leo,
> >
> > Works for us. I plan to send HDBSS v5 maybe next week with this series
> > merged in. Both dirty-tracking consumers are already built on top of the
> > DBM approach: dirty ring and dirty bitmap.
> >
> > Leo, with your blessing, I'd like to pick patches 1-4 into the HDBSS
> > tree with your Signed-off-by preserved and mine added on top, plus some
> > bug fixes on top of this RFC series.
>
> Yeah, no problem on my side. I would just observe the maintainers' comments
> on those before merging them.

All right, thanks.

Tian

> > For patch 5, I'd like to rework it into a derived hardware dirty mode
> > that replaces both kvm_set_hafdbs() and our earlier HDBSS enable/disable
> > hooks, so the whole thing lands as one series.
>
> My intention when I wrote that patch was to add a base so you could add
> HDBSS on kvm_arch_commit_memory_region() with new patch such as:
>
> 	/* Disable HAFDBS when dirty-logging starts */
> 	if (kvm_supports_hafdbs(kvm))
> 		kvm_set_hafdbs(kvm, 0);
> +	else
> +		kvm_enable_hdbss(kvm);
> ...
>
> 	/* If dirty-logging was canceled, set HAFDBS back on */
> 	if (kvm_supports_hafdbs(kvm) &&
> 	    atomic_read(&kvm->nr_memslots_dirty_logging) == 0)
> 		kvm_set_hafdbs(kvm, 1);
> +	else
> +		kvm_disable_hdbss(kvm);
>
>
> That being said, I need to run tests to make sure the usage of HAFDBS
> outside of dirty_tracking makes any sense in terms of performance, but if
> that's not the case, it would be fine to rework it so it does not
> enable/disable HAFDBS there.
>
> > Performance looks good in both dirty ring and dirty bitmap scenarios so
> > far.
>
> Awesome!
>
> Thanks!
> Leo