Re: [PATCH v4 0/6] Support the FEAT_HDBSS introduced in Armv9.5

[Leonardo Bras]

On Tue, Jul 14, 2026 at 05:37:58PM +0800, Tian Zheng wrote:
> 
> On 7/13/2026 6:31 PM, Leonardo Bras wrote:
> > On Thu, Jul 09, 2026 at 06:40:20PM +0800, Tian Zheng wrote:
> > > This series of patches add support to the Hardware Dirty state tracking
> > > Structure (HDBSS) feature, which is introduced by the ARM architecture
> > > in the DDI0601 (ID121123) version.
> > > 
> > > The HDBSS feature is an extension to the architecture that enhances
> > > tracking translation table descriptors' dirty state, identified as
> > > FEAT_HDBSS. This feature utilizes hardware assistance to achieve dirty
> > > page tracking, aiming to significantly reduce the overhead of scanning
> > > for dirty pages.
> > > 
> > > The purpose of this feature is to make the execution overhead of live
> > > migration lower to both the guest and the host, compared to existing
> > > approaches (write-protect or search stage-2 tables).
> > > 
> > > The required sysreg definitions for FEAT_HDBSS have been merged into
> > > arm64 /sysregs:
> > >    [1/5] arm64/sysreg: Add HDBSS related register information
> > >          https://git.kernel.org/arm64/c/72f7be0c2e30
> > > 
> > > 
> > > After these patches, the kernel automatically enables HDBSS when dirty
> > > logging is enabled on any memslot, and disables HDBSS when dirty logging
> > > is disabled on all memslots. This series does not support dirty ring
> > > mode.
> > > 
> > > Depends-on: "KVM: arm64: Enable eager hugepage splitting if HDBSS is available"
> > > 	https://lore.kernel.org/linux-arm-kernel/20260629111820.1873540-3-leo.bras@xxxxxxx/
> > On this, FYI, there have been some discussion on this:
> > https://lore.kernel.org/all/alETGFD2Ogx6N0HB@LeoBrasDK/
> > 
> > Oliver's suggestion is that we don't automatically enable eager splitting,
> > but instead we have different behaviours if the user enables it.
> > 
> > This is still under discussion there, but I think it can be useful reading.
> 
> 
> Thanks for the pointer — I've read through the discussion between you and
> Oliver, and it's very helpful.
> 
> 
> If I understand correctly, the proposed approach is to support both modes,
> with DBM behavior depending
> 
> on the user's eager split setting:

I am still waiting for his feedback on that, but I suppose that's what he 
meant.


> 
> - If users enable eager splitting (chunk_size != 0): use the v4 approach —
> DBM is set globally.
> 
> - If users do NOT enable eager splitting (chunk_size == 0, i.e., lazy split
> mode): use the v3 approach — DBM
> 
> is set lazily in user_mem_abort on the first write fault.
> 
> 
> This makes sense to me. It gives users the flexibility to choose.
> 

Yes, agree

> 
> As I mentioned in my patch 6/6 reply (https://lore.kernel.org/all/6e8b23bc-d420-4f5a-a921-5a5d64d84200@xxxxxxxxxx/),
> 
> I do think the lazy DBM approach is safer overall if the first-fault
> overhead is acceptable — it avoids accidentally marking
> 
> special mappings and naturally handles lazy split.
> 

I remember a previous discussion in which was concluded that lazy marking 
DBM carried some issues. I have to go back on that and check if we can take 
care of that now.  

> 
> I'll keep an eye on the discussion and follow up once a conclusion is
> reached.
> 

Thanks!
Leo