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

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

On Thu, Apr 02, 2026 at 10:40:37AM +0800, Tian Zheng wrote:
> 
> On 3/31/2026 10:13 PM, Leonardo Bras wrote:
> > On Wed, Feb 25, 2026 at 12:04:16PM +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).
> > > 
> > > After these patches, users(such as qemu) can use the
> > > KVM_CAP_ARM_HW_DIRTY_STATE_TRACK ioctl to enable or disable the HDBSS
> > > feature before and after the live migration.
> > > 
> > > v2:
> > > https://lore.kernel.org/linux-arm-kernel/20251121092342.3393318-1-zhengtian10@huawei.com/
> > > 
> > > v2->v3 changes:
> > > - Remove the ARM64_HDBSS configuration option and ensure this feature
> > > is only enabled in VHE mode.
> > > - Move HDBSS-related variables to the arch-independent portion of the
> > > kvm structure.
> > > - Remove error messages during HDBSS enable/disable operations
> > > - Change HDBSS buffer flushing from handle_exit to vcpu_put,
> > > check_vcpu_requests, and kvm_handle_guest_abort.
> > > - Add fault handling for HDBSS including buffer full, external abort,
> > > and general protection fault (GPF).
> > > - Add support for a 4KB HDBSS buffer size, mapped to the value 0b0000.
> > > - Add a second argument to the ioctl to turn HDBSS on or off.
> > > 
> > > Tian Zheng (1):
> > >    KVM: arm64: Document HDBSS ioctl
> > > 
> > > eillon (4):
> > >    arm64/sysreg: Add HDBSS related register information
> > >    KVM: arm64: Add support to set the DBM attr during memory abort
> > >    KVM: arm64: Add support for FEAT_HDBSS
> > >    KVM: arm64: Enable HDBSS support and handle HDBSSF events
> > > 
> > >   Documentation/virt/kvm/api.rst       |  16 +++++
> > >   arch/arm64/include/asm/cpufeature.h  |   5 ++
> > >   arch/arm64/include/asm/esr.h         |   7 ++
> > >   arch/arm64/include/asm/kvm_host.h    |  17 +++++
> > >   arch/arm64/include/asm/kvm_mmu.h     |   1 +
> > >   arch/arm64/include/asm/kvm_pgtable.h |   4 ++
> > >   arch/arm64/include/asm/sysreg.h      |  11 +++
> > >   arch/arm64/kernel/cpufeature.c       |  12 ++++
> > >   arch/arm64/kvm/arm.c                 | 102 +++++++++++++++++++++++++++
> > >   arch/arm64/kvm/hyp/pgtable.c         |   6 ++
> > >   arch/arm64/kvm/hyp/vhe/switch.c      |  19 +++++
> > >   arch/arm64/kvm/mmu.c                 |  70 ++++++++++++++++++
> > >   arch/arm64/kvm/reset.c               |   3 +
> > >   arch/arm64/tools/cpucaps             |   1 +
> > >   arch/arm64/tools/sysreg              |  29 ++++++++
> > >   include/uapi/linux/kvm.h             |   1 +
> > >   tools/include/uapi/linux/kvm.h       |   1 +
> > >   17 files changed, 305 insertions(+)
> > > 
> > > --
> > > 2.33.0
> > > 
> > 
> > Hi Tian,
> > 
> > I was thinking: maybe instead of putting the HDBSS (and HACDBS) stuff
> > across a bunch of KVM files, we should try to focus them all on a single
> > arch/arm64/kvm/dirty_bit.c file (plus a header such as
> > arch/arm64/include/asm/kvm_dirty_bit.h).
> > 
> > What is your opinion on that?
> > 
> > Thanks!
> > Leo
> 
> 
> Sorry for the late reply. Yes, I had the same thought before. In the next
> version, I will
> 
> move all the HDBSS-related content into the same file, such as
> arch/arm64/kvm/dirty_bit.c
> 
> and arch/arm64/include/asm/kvm_dirty_bit.h.
> 
> 
> Tian
> 
> 
> > 
> > 


Awesome! Then I will work my HACDBS enablement that way as well.

Thanks!
Leo