Re: [PATCH v3 3/5] KVM: arm64: Add support for FEAT_HDBSS

[Marc Zyngier <maz@kernel.org>]

On Mon, 01 Jun 2026 01:50:22 +0100,
Inochi Amaoto <inochiama@gmail.com> wrote:
> 
> On Wed, Feb 25, 2026 at 12:04:19PM +0800, Tian Zheng wrote:
> > From: eillon <yezhenyu2@huawei.com>
> > 
> > Armv9.5 introduces the Hardware Dirty Bit State Structure (HDBSS) feature,
> > indicated by ID_AA64MMFR1_EL1.HAFDBS == 0b0100. A CPU capability is added
> > to notify the user of the feature.
> > 
> > Add KVM_CAP_ARM_HW_DIRTY_STATE_TRACK ioctl and basic framework for
> > ARM64 HDBSS support. Since the HDBSS buffer size is configurable and
> > cannot be determined at KVM initialization, an IOCTL interface is
> > required.
> > 
> > Actually exposing the new capability to user space happens in a later
> > patch.
> > 
> > Signed-off-by: eillon <yezhenyu2@huawei.com>
> > Signed-off-by: Tian Zheng <zhengtian10@huawei.com>
> > ---
> >  arch/arm64/include/asm/cpufeature.h |  5 +++++
> >  arch/arm64/kernel/cpufeature.c      | 12 ++++++++++++
> >  arch/arm64/tools/cpucaps            |  1 +
> >  include/uapi/linux/kvm.h            |  1 +
> >  tools/include/uapi/linux/kvm.h      |  1 +
> >  5 files changed, 20 insertions(+)
> > 
> > diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
> > index 4de51f8d92cb..dcc2e2cad5ad 100644
> > --- a/arch/arm64/include/asm/cpufeature.h
> > +++ b/arch/arm64/include/asm/cpufeature.h
> > @@ -856,6 +856,11 @@ static inline bool system_supports_haft(void)
> >  	return cpus_have_final_cap(ARM64_HAFT);
> >  }
> > 
> > +static inline bool system_supports_hdbss(void)
> > +{
> > +	return cpus_have_final_cap(ARM64_HAS_HDBSS);
> > +}
> > +
> >  static __always_inline bool system_supports_mpam(void)
> >  {
> >  	return alternative_has_cap_unlikely(ARM64_MPAM);
> > diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> > index c31f8e17732a..348b0afffc3e 100644
> > --- a/arch/arm64/kernel/cpufeature.c
> > +++ b/arch/arm64/kernel/cpufeature.c
> > @@ -2124,6 +2124,11 @@ static bool hvhe_possible(const struct arm64_cpu_capabilities *entry,
> >  	return arm64_test_sw_feature_override(ARM64_SW_FEATURE_OVERRIDE_HVHE);
> >  }
> > 
> > +static bool has_vhe_hdbss(const struct arm64_cpu_capabilities *entry, int cope)
> > +{
> > +	return is_kernel_in_hyp_mode() && has_cpuid_feature(entry, cope);
> > +}
> > +
> >  bool cpu_supports_bbml2_noabort(void)
> >  {
> >  	/*
> > @@ -2759,6 +2764,13 @@ static const struct arm64_cpu_capabilities arm64_features[] = {
> >  		ARM64_CPUID_FIELDS(ID_AA64MMFR1_EL1, HAFDBS, HAFT)
> >  	},
> >  #endif
> > +	{
> > +		.desc = "Hardware Dirty state tracking structure (HDBSS)",
> > +		.type = ARM64_CPUCAP_SYSTEM_FEATURE,
> > +		.capability = ARM64_HAS_HDBSS,
> > +		.matches = has_vhe_hdbss,
> > +		ARM64_CPUID_FIELDS(ID_AA64MMFR1_EL1, HAFDBS, HDBSS)
> > +	},
> >  	{
> >  		.desc = "CRC32 instructions",
> >  		.capability = ARM64_HAS_CRC32,
> > diff --git a/arch/arm64/tools/cpucaps b/arch/arm64/tools/cpucaps
> > index 7261553b644b..f6ece5b85532 100644
> > --- a/arch/arm64/tools/cpucaps
> > +++ b/arch/arm64/tools/cpucaps
> > @@ -68,6 +68,7 @@ HAS_VA52
> >  HAS_VIRT_HOST_EXTN
> >  HAS_WFXT
> >  HAS_XNX
> > +HAS_HDBSS
> >  HAFT
> >  HW_DBM
> >  KVM_HVHE
> 
> 
> > diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> > index 65500f5db379..15ee42cdbd51 100644
> > --- a/include/uapi/linux/kvm.h
> > +++ b/include/uapi/linux/kvm.h
> > @@ -985,6 +985,7 @@ struct kvm_enable_cap {
> >  #define KVM_CAP_ARM_SEA_TO_USER 245
> >  #define KVM_CAP_S390_USER_OPEREXEC 246
> >  #define KVM_CAP_S390_KEYOP 247
> > +#define KVM_CAP_ARM_HW_DIRTY_STATE_TRACK 248
> > 
> >  struct kvm_irq_routing_irqchip {
> >  	__u32 irqchip;
> > diff --git a/tools/include/uapi/linux/kvm.h b/tools/include/uapi/linux/kvm.h
> > index dddb781b0507..93e0a1e14dc7 100644
> > --- a/tools/include/uapi/linux/kvm.h
> > +++ b/tools/include/uapi/linux/kvm.h
> > @@ -974,6 +974,7 @@ struct kvm_enable_cap {
> >  #define KVM_CAP_GUEST_MEMFD_FLAGS 244
> >  #define KVM_CAP_ARM_SEA_TO_USER 245
> >  #define KVM_CAP_S390_USER_OPEREXEC 246
> > +#define KVM_CAP_ARM_HW_DIRTY_STATE_TRACK 248
> > 
> >  struct kvm_irq_routing_irqchip {
> >  	__u32 irqchip;
> > --
> > 2.33.0
> > 
> 
> Instead of having these architecture specific capability, I wonder if
> we can add a generic capability like "KVM_CAP_HW_DIRTY_STATE", so
> other architecture supports similar things can reuse this capability,

What of the existing stuff doing the same thing? x86's PML, to start
with?

> For this generic thing I suggest, the getter returns the max support 
> entry count (or the buffer size) it supports like the dirty ring
> capability. And the setter just let the architecture set the parameters
> based on the user request.

This looks wrong on a number of levels.

- If you want something generic, there is the existing dirty
  log/bitmap. How this stuff is populated is none of the user's
  business (trapping write accesses, dirty bit collection from the
  PTs, or HW-generated log), and we don't need an extra feature for
  it. Performance will obviously suck, but that's what you pay for
  something abstracted and cross-architecture.

- If you want something architecture specific, then it can't be
  generic, by definition. You get the raw speed and compatibility with
  other arch-specific extensions.

> This should do no harm to this implement, as everything still depends
> on the architecture behavior, and leave room for other architecture
> to reuse this.

Again, the generic framework exists, you just have to implement the
backend you want.

	M.

-- 
Without deviation from the norm, progress is not possible.