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

[Inochi Amaoto <inochiama@gmail.com>]

On Mon, Jun 01, 2026 at 09:58:49AM +0100, Marc Zyngier wrote:
> 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?
> 

In fact I think the HDBSS is the first one with non-fixed size.
Although there is a in process RISC-V extension for it, there will
be a long story to make it ratified.

> > 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.
> 

OK, I agree, it is better to keep this thing arch-specific. Doing a
generic thing does not benefit too much, I have made a mistake on
it. Thanks for your kindly explanation.

> > 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.

Regards,
Inochi