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

[Leonardo Bras <leo.bras@arm.com>]

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.

> 
> 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