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

[Oliver Upton]

On Tue, Oct 27, 2026 at 11:44:15AM +0000, Leonardo Bras wrote:
> > 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.
> >
> 
> Right, 
> My reasoning is that we can discuss this new version, and make the needed 
> changes, so Tian could pick this for his own patch series for the next 
> version. I do not intend to get this merged by itself.
> 
> Next time I will make sure to state this in the cover letter so it's clear.

Can you just work this out off-list? Let's keep the on-list dialogue
consolidated to a single series to review.

> > 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
> > 
> 
> I agree that it could work, and my first version was based on that.
> 
> But looks weird to me that we have to decide the writable bit based on 
> having a feature enabled.
> 
> Take in account that we can only have DBM being the writable bit while 
> HAFDBS is enabled (not only present), and that it is just enabled during 
> dirty-tracking. 
> 
> It means we would need to convert the whole pagetable between DIRTY=S2AP[1] 
> and DIRTY=DBM every time we enable or disable dirty-tracking.
> 
> My suggestion with this series is to have WRITE=DIRTY=S2AP[1] at all 
> times, and have DBM to act as a "can be promoted to writable on write" bit.
> This way we don't actually need to convert between encodings, and it still 
> works and complies with the architecture.

There's no such "can be promoted to writable on write" in the indirect
permission model. This is why I'm suggesting that we align the abstract
permission bits (i.e. KVM_PGTABLE_PROT_*) with the architecture's own
abstracted permissions (e.g. uX, pX, RO, RW).

That composes nicely with nested virt as it is unambiguous what
permissions we're trying to represent in a shadow stage-2. And in the
non-nested case you can just lay down writable-dirty translations for
most things and use writable-clean when necessary for HDBSS.

> > 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.
> 
> Humm, and would not that work with the above suggested approach?
> I mean, bit 7 (Dirty, S2AP[1]) will both mean WRITE/DIRTY, but it will be 
> able to get promoted (nonW->W, or clean->dirty) based on the indirect 
> permissions.

There's a bit more though. We need to have an entry in S2PIR_EL2 that
encodes write permission and select that with PIIndex. So then we wind
up mapping the abstract WRITE permission bit to two fields into the
descriptor rather than 1.