[RFC PATCH v2 0/3] Set DBM bit on writable pages

[Oliver Upton]

On Mon, Oct 26, 2026 at 02:44:06PM +0000, Leonardo Bras wrote:
> When HAFDBS is enabled (VTCR_EL2.{HA,HD}={1,1}), having a DBM bit allows 
> hardware to promote a non-writable page to writable by setting (S2AP[1]=1),
> without having to take a fault.
> 
> The reason for this patchset is to add the DBM bit when setting-up writable 
> pages, so the code is prepared for future patches that make use of 
> HDBSS/HACDBS to accelerate dirty-tracking. Write-bit detection still 
> happens based only in S2AP[1], so no change in that aspect.
> 
> Having DBM set on block entries is undesired, as we benefit from the first 
> fault for splitting it in PAGE_SIZE entries, which is the granularity used 
> to track the dirty pages in KVM. So introduce a new walker that, on top of 
> clearing S2AP[1] for every entry, also clear DBM for block entries.
> 
> Also introduce a new VCPU request to reload Stage2, as it will be needed on 
> future HDBSS/HAFDBS patchsets. 
> 
> Please let me know of what do you think!

I'm pretty sure I shared this feedback before, but patches that enable
DBM do not make sense in isolation. We need a single series that
contains the DBM enablement as well as the corresponding HDBSS support.

> Changes since RFCv1:
> - Dropped patch #5 on enabling HAFDBS on non-dirty-tracking guests, as it 
>   proved to be counter-productive on wrprotect, contrary to expectations
> - No more moving writable-bit to DBM. That does not seem to be the intended 
>   use. It makes sense and it's easier to convert code to new DBM approach.

Sorry, where was this concluded?

The abstract permission flags need to have a WRITE an DIRTY state, which
we then map to hardware based on the capabilities of the system.

!FEAT_HAFDBS:

	DIRTY	=> S2AP[1]
	WRITE	=> S2AP[1]

FEAT_HAFDBS:

	DIRTY	=> S2AP[1]
	WRITE	=> DBM

Beyond making the whole HAFDBS easy to reason about, I want this for
FEAT_S2PIE which reimagines bit 7 as a literal dirty bit that can be
managed by software or hardware.

Thanks,
Oliver