From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id CB78DCFC538 for ; Sat, 22 Nov 2025 13:25:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type:MIME-Version: References:In-Reply-To:Subject:Cc:To:From:Message-ID:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=y+FWXqUAeSub0JOoxZkXhN3IQ/05DjSS+/uicwaJQDM=; b=yCSJpioBEqCBtf6cQ7hc3qzbIT vK2jViNn3brWkcTUdl9WvCjJrEQB1GgfjDMNmF9D9avSRYsMtg+US9tRwRASkLXZVAouQJAelw5C7 A86gpVEog1uuOuZG+EEkexu+1R+QlkA3wzHYAkr2XP7nFL2flnS3ikt8BdvODvsl0f0qyu9FfIcGK /xUgvi5YHonCJOygi0VH1zZf7BwB2dL+XRC0LK05wNuVDBSJMnLUitf1xfnxc4Vzyo3HX6riGO0h5 a//cDbSUQvjBd+UsZfFXzBq3240rvXkbrJhrC8+HD4yjV4REpoZ1fodH0tNBoRISbJSmU6QZlWrYZ V9deSzKw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1vMncK-00000009cL0-2aV4; Sat, 22 Nov 2025 13:25:32 +0000 Received: from sea.source.kernel.org ([172.234.252.31]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1vMncI-00000009cKd-1O3I for linux-arm-kernel@lists.infradead.org; Sat, 22 Nov 2025 13:25:31 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 8279A407E6; Sat, 22 Nov 2025 13:25:27 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 36870C4CEF5; Sat, 22 Nov 2025 13:25:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1763817927; bh=e5AzHO81/a9aj3GGCW5h753xla0jVym/io664XMZHaI=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=MPFqf4s97YnlpFpPgLeDgfSjRJDbo4g8ily8P1JGPTsEdLK4SavjKLSbGof22Tlsk 1GXUs8Rgj342YdjdSXJMmnxmr5ZY4NScgsmX+lEXlaNAtM8rb5cPv2T2fcAx5VXqKH xVwo/q0If8WQDQAjb+fB0pD3APpSjI5DgURuyE8Wypb0CTSbSFKttkmBA+q7guCcPV f1LRXKToE/rvYbj3/ETtCMO599A8X/Yajovd4IYCtDwynCKBgYll4DVNTcJp1bVTxN ncMnxbsZvW5jK0t+hzsYQf7sAYzUwwOldwOFZe6TKYUEd89fThSlCDm5P5HnPAt951 TsQca6TBCJTOA== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1vMncC-00000007UgK-44UT; Sat, 22 Nov 2025 13:25:25 +0000 Date: Sat, 22 Nov 2025 13:25:24 +0000 Message-ID: <86tsymqjwb.wl-maz@kernel.org> From: Marc Zyngier To: Tian Zheng Cc: , , , , , , , , , , , , , , , , , Subject: Re: [PATCH v2 3/5] KVM: arm64: Add support for FEAT_HDBSS In-Reply-To: <20251121092342.3393318-4-zhengtian10@huawei.com> References: <20251121092342.3393318-1-zhengtian10@huawei.com> <20251121092342.3393318-4-zhengtian10@huawei.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: zhengtian10@huawei.com, 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 X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20251122_052530_413917_7227E783 X-CRM114-Status: GOOD ( 34.85 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, 21 Nov 2025 09:23:40 +0000, Tian Zheng wrote: > > From: eillon > > 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 > Signed-off-by: Tian Zheng > --- > 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.