linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
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.


  reply	other threads:[~2025-11-22 13:25 UTC|newest]

Thread overview: 21+ 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
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
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
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).