From: Marc Zyngier <maz@kernel.org>
To: Tian Zheng <zhengtian10@huawei.com>
Cc: <oliver.upton@linux.dev>, <catalin.marinas@arm.com>,
<corbet@lwn.net>, <pbonzini@redhat.com>, <will@kernel.org>,
<linux-kernel@vger.kernel.org>, <yuzenghui@huawei.com>,
<wangzhou1@hisilicon.com>, <yezhenyu2@huawei.com>,
<xiexiangyou@huawei.com>, <zhengchuan@huawei.com>,
<linuxarm@huawei.com>, <joey.gouly@arm.com>,
<kvmarm@lists.linux.dev>, <kvm@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
<linux-doc@vger.kernel.org>, <suzuki.poulose@arm.com>
Subject: Re: [PATCH v2 3/5] KVM: arm64: Add support for FEAT_HDBSS
Date: Sat, 22 Nov 2025 13:25:24 +0000 [thread overview]
Message-ID: <86tsymqjwb.wl-maz@kernel.org> (raw)
In-Reply-To: <20251121092342.3393318-4-zhengtian10@huawei.com>
On Fri, 21 Nov 2025 09:23:40 +0000,
Tian Zheng <zhengtian10@huawei.com> wrote:
>
> From: eillon <yezhenyu2@huawei.com>
>
> Armv9.5 introduces the Hardware Dirty Bit State Structure (HDBSS) feature,
> indicated by ID_AA64MMFR1_EL1.HAFDBS == 0b0100.
>
> Add the Kconfig for FEAT_HDBSS and support detecting and enabling the
> feature. 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/Kconfig | 14 ++++++++++++++
> arch/arm64/include/asm/cpucaps.h | 2 ++
> arch/arm64/include/asm/cpufeature.h | 5 +++++
> arch/arm64/include/asm/kvm_host.h | 4 ++++
> arch/arm64/include/asm/sysreg.h | 12 ++++++++++++
> arch/arm64/kernel/cpufeature.c | 9 +++++++++
> arch/arm64/tools/cpucaps | 1 +
> include/uapi/linux/kvm.h | 1 +
> tools/include/uapi/linux/kvm.h | 1 +
> 9 files changed, 49 insertions(+)
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 6663ffd23f25..1edf75888a09 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -2201,6 +2201,20 @@ config ARM64_GCS
>
> endmenu # "ARMv9.4 architectural features"
>
> +menu "ARMv9.5 architectural features"
> +
> +config ARM64_HDBSS
> + bool "Enable support for Hardware Dirty state tracking Structure (HDBSS)"
> + help
> + Hardware Dirty state tracking Structure(HDBSS) enhances tracking
> + translation table descriptors' dirty state to reduce the cost of
> + surveying for dirtied granules.
> +
> + The feature introduces new assembly registers (HDBSSBR_EL2 and
> + HDBSSPROD_EL2), which are accessed via generated register accessors.
This last but means nothing to most people.
But more importantly, I really don't want to see this as a config
option. KVM comes with "battery included", and all features should be
available at all times.
> +
> +endmenu # "ARMv9.5 architectural features"
> +
> config ARM64_SVE
> bool "ARM Scalable Vector Extension support"
> default y
> diff --git a/arch/arm64/include/asm/cpucaps.h b/arch/arm64/include/asm/cpucaps.h
> index 9d769291a306..5e5a26f28dec 100644
> --- a/arch/arm64/include/asm/cpucaps.h
> +++ b/arch/arm64/include/asm/cpucaps.h
> @@ -48,6 +48,8 @@ cpucap_is_possible(const unsigned int cap)
> return IS_ENABLED(CONFIG_ARM64_GCS);
> case ARM64_HAFT:
> return IS_ENABLED(CONFIG_ARM64_HAFT);
> + case ARM64_HAS_HDBSS:
> + return IS_ENABLED(CONFIG_ARM64_HDBSS);
> case ARM64_UNMAP_KERNEL_AT_EL0:
> return IS_ENABLED(CONFIG_UNMAP_KERNEL_AT_EL0);
> case ARM64_WORKAROUND_843419:
> diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
> index e223cbf350e4..b231415a2b76 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/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index 64302c438355..d962932f0e5f 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -60,6 +60,10 @@
>
> #define KVM_HAVE_MMU_RWLOCK
>
> +/* HDBSS entry field definitions */
> +#define HDBSS_ENTRY_VALID BIT(0)
> +#define HDBSS_ENTRY_IPA GENMASK_ULL(55, 12)
> +
None of this is used here. Move it to the patch where it belongs.
> /*
> * Mode of operation configurable with kvm-arm.mode early param.
> * See Documentation/admin-guide/kernel-parameters.txt for more information.
> diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
> index c231d2a3e515..3511edea1fbc 100644
> --- a/arch/arm64/include/asm/sysreg.h
> +++ b/arch/arm64/include/asm/sysreg.h
> @@ -1129,6 +1129,18 @@
> #define gicr_insn(insn) read_sysreg_s(GICV5_OP_GICR_##insn)
> #define gic_insn(v, insn) write_sysreg_s(v, GICV5_OP_GIC_##insn)
>
> +/*
> + * Definitions for the HDBSS feature
> + */
> +#define HDBSS_MAX_SIZE HDBSSBR_EL2_SZ_2MB
> +
> +#define HDBSSBR_EL2(baddr, sz) (((baddr) & GENMASK(55, 12 + sz)) | \
> + FIELD_PREP(HDBSSBR_EL2_SZ_MASK, sz))
> +#define HDBSSBR_BADDR(br) ((br) & GENMASK(55, (12 + HDBSSBR_SZ(br))))
> +#define HDBSSBR_SZ(br) FIELD_GET(HDBSSBR_EL2_SZ_MASK, br)
This is a bit backward. When would you need to read-back and mask
random bits off the register?
> +
> +#define HDBSSPROD_IDX(prod) FIELD_GET(HDBSSPROD_EL2_INDEX_MASK, prod)
> +
As previously said, these definitions don't serve any purpose here,
and would be better in the following patch.
> #define ARM64_FEATURE_FIELD_BITS 4
>
> #ifdef __ASSEMBLY__
> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> index e25b0f84a22d..f39973b68bdb 100644
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@ -2710,6 +2710,15 @@ static const struct arm64_cpu_capabilities arm64_features[] = {
> .matches = has_cpuid_feature,
> ARM64_CPUID_FIELDS(ID_AA64MMFR1_EL1, HAFDBS, HAFT)
> },
> +#endif
> +#ifdef CONFIG_ARM64_HDBSS
> + {
> + .desc = "Hardware Dirty state tracking structure (HDBSS)",
> + .type = ARM64_CPUCAP_SYSTEM_FEATURE,
> + .capability = ARM64_HAS_HDBSS,
> + .matches = has_cpuid_feature,
> + ARM64_CPUID_FIELDS(ID_AA64MMFR1_EL1, HAFDBS, HDBSS)
> + },
I think this is one of the features we should restrict to VHE. I don't
imagine pKVM ever making use of this, and no non-VHE HW will ever
build this.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
next prev parent reply other threads:[~2025-11-22 13:25 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-21 9:23 [PATCH v2 0/5] Support the FEAT_HDBSS introduced in Armv9.5 Tian Zheng
2025-11-21 9:23 ` [PATCH v2 1/5] arm64/sysreg: Add HDBSS related register information Tian Zheng
2025-11-22 12:40 ` Marc Zyngier
2025-11-27 11:48 ` Tian Zheng
2025-12-02 6:51 ` Tian Zheng
2026-01-22 15:12 ` Leonardo Bras
2026-01-22 15:16 ` Leonardo Bras
2026-01-23 10:15 ` Marc Zyngier
2026-01-26 2:21 ` Tian Zheng
2026-01-26 11:50 ` Leonardo Bras
2025-11-21 9:23 ` [PATCH v2 2/5] KVM: arm64: Support set the DBM attr during memory abort Tian Zheng
2025-11-22 12:54 ` Marc Zyngier
2025-11-27 12:19 ` Tian Zheng
2026-01-29 17:02 ` Leonardo Bras
2026-01-29 18:48 ` Marc Zyngier
2025-11-21 9:23 ` [PATCH v2 3/5] KVM: arm64: Add support for FEAT_HDBSS Tian Zheng
2025-11-22 13:25 ` Marc Zyngier [this message]
2025-11-27 13:24 ` Tian Zheng
2025-11-21 9:23 ` [PATCH v2 4/5] KVM: arm64: Enable HDBSS support and handle HDBSSF events Tian Zheng
2025-11-22 16:17 ` Marc Zyngier
2025-11-28 9:21 ` Tian Zheng
2025-12-17 13:39 ` Robert Hoo
2025-12-24 6:15 ` Tian Zheng
2025-12-28 13:21 ` Robert Hoo
2026-01-09 7:52 ` Tian Zheng
2025-11-21 9:23 ` [PATCH v2 5/5] KVM: arm64: Document HDBSS ioctl Tian Zheng
2025-11-21 9:54 ` [PATCH v2 0/5] Support the FEAT_HDBSS introduced in Armv9.5 Marc Zyngier
2025-11-21 10:21 ` z00939249
2025-11-22 16:23 ` Marc Zyngier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86tsymqjwb.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=corbet@lwn.net \
--cc=joey.gouly@arm.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=oliver.upton@linux.dev \
--cc=pbonzini@redhat.com \
--cc=suzuki.poulose@arm.com \
--cc=wangzhou1@hisilicon.com \
--cc=will@kernel.org \
--cc=xiexiangyou@huawei.com \
--cc=yezhenyu2@huawei.com \
--cc=yuzenghui@huawei.com \
--cc=zhengchuan@huawei.com \
--cc=zhengtian10@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.