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

[Tian Zheng <zhengtian10@huawei.com>]

On 6/1/2026 5:05 PM, Inochi Amaoto wrote:
> 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.


Awesome. Thanks for the review.

I agree with Marc—keeping this ARM-specific is the right approach.
Also, in v4 we're removing the ioctl interface entirely. HDBSS will be
auto-enabled during migration setup and auto-disabled when migration
completes, so the capability naming issue becomes moot.

I plan to post v4 with the updated approach soon.


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