Re: [PATCH v4 0/6] Support the FEAT_HDBSS introduced in Armv9.5
From: Tian Zheng
Date: Tue Jul 14 2026 - 09:41:26 EST
On 7/14/2026 6:19 PM, Leonardo Bras wrote:
On Tue, Jul 14, 2026 at 05:37:58PM +0800, Tian Zheng wrote:All right, I'll support both split modes with different DBM methods in the next version.
On 7/13/2026 6:31 PM, Leonardo Bras wrote:I am still waiting for his feedback on that, but I suppose that's what he
On Thu, Jul 09, 2026 at 06:40:20PM +0800, Tian Zheng wrote:
This series of patches add support to the Hardware Dirty state trackingOn this, FYI, there have been some discussion on this:
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/
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:
meant.
- If users enable eager splitting (chunk_size != 0): use the v4 approach —Yes, agree
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.
As I mentioned in my patch 6/6 reply (https://lore.kernel.org/all/6e8b23bc-d420-4f5a-a921-5a5d64d84200@xxxxxxxxxx/),I remember a previous discussion in which was concluded that lazy marking
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.
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 isThanks!
reached.
Leo
Please let me know once you've had a chance to revisit the previous lazy DBM issues — happy to adjust if needed.
Thanks!
Tian