[PATCH v3 3/5] KVM: arm64: Add support for FEAT_HDBSS
Tian Zheng
zhengtian10 at huawei.com
Mon Jul 6 23:11:23 PDT 2026
On 7/6/2026 10:01 PM, Leonardo Bras wrote:
> On Fri, Jun 05, 2026 at 04:29:49PM +0800, Tian Zheng wrote:
>> 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 at gmail.com> wrote:
>>>>> On Wed, Feb 25, 2026 at 12:04:19PM +0800, Tian Zheng wrote:
>>>>>> From: eillon <yezhenyu2 at 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 at huawei.com>
>>>>>> Signed-off-by: Tian Zheng <zhengtian10 at 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.
> Hi Tian,
>
> Any updates in the v4?
> Please let me know if you want help in any kind, in regards to this
> patchset.
>
> Thanks!
> Leo
Hi Leo,
Thanks for the follow-up. I've finished polishing v4 and am doing one
last internal review.
In this version, I've also aligned with the latest HACDBS v2
implementation you shared—e.g.,
auto-inserting KVM_PGTABLE_S2_DBM into pgt->flags during
kvm_init_stage2_mmu.
One note: dirty ring mode is not yet supported in v4—the series
currently focuses on the
dirty bitmap mode. I'll explicitly call this out in the commit messages
(including that
KVM_DIRTY_LOG_MANUAL_PROTECT_ENABLE and related dirty ring components
are omitted) to avoid
any confusion during review.
I plan to send v4 out later this week.
Thanks,
Tian
More information about the linux-arm-kernel
mailing list