From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-oi1-f173.google.com (mail-oi1-f173.google.com [209.85.167.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 576E63FC5D0 for ; Tue, 19 May 2026 17:31:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.167.173 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779211881; cv=none; b=odPGYczyVLuxX2UCiJvYF0G/tgOZoq8w2HbiAD4Q70zkA6ObfeJJHl0xskAuk4WSy4TfhtA2wImKy6680DMDv4JcYCNsm/BbUZGQdDjNxjyO1M3m8CbYn6v4VMX15U/tUwkn1shljZe1HX6IDovCKY2Rbj7lia76PHR983vxiSw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779211881; c=relaxed/simple; bh=GJU2Nki/RSF3sj6Rfw0sHvYBo+ZgflCeniEGdZ5/pZ0=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=TcekzTuqbYiiFThT+jBJ3WxClQcnuPZBGcNFHrQjyw+zo47sPQX7RhhlOzotJznbuMf0qcJtaP01OXHGN0oaBw7oRldPlI2tIENy40ni3GQviNeWblRgpStUPb6UusGJ/Re/cnb758IiQ/UPN/Io0Rd+ZV3Yqsl6BfU1bbVpYVQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=sifive.com; spf=pass smtp.mailfrom=sifive.com; dkim=pass (2048-bit key) header.d=sifive.com header.i=@sifive.com header.b=ZB7lyUTW; arc=none smtp.client-ip=209.85.167.173 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=sifive.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=sifive.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=sifive.com header.i=@sifive.com header.b="ZB7lyUTW" Received: by mail-oi1-f173.google.com with SMTP id 5614622812f47-479ef2b78f3so3685330b6e.2 for ; Tue, 19 May 2026 10:31:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; t=1779211879; x=1779816679; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:content-language:from :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=+M43gBW8YyjmiDrGj03/O7lQi+1aZT7Iw8k13I+uBgA=; b=ZB7lyUTWKxrv5VB5v/qXsOIJk0wS/hEtsEaRv7rZlkdmEWhqlqsA8zqxGD2vtxQg7e 65tfeiM9idX1PIHCyZll2WnNHe4ijTu0o5EWtg3xb8v6cBl0b5u8h1WzsN8g+HRWapnG y+gRb91sLAQY+xu3uAVYfHfFfwi88odscGZgo5NkQUxTZLdLPkL/f3SCe8s2ghZq+ane u/ZCnpJWaMTw/l5nhsLk4TYFLYflMaZ0j8uo0f/ROtzJ01YJnQJzDMIIpUBqqk1TDKTN roiRkAbVjNzl3bcp9AyBOBi8xBKmUTv59XczAZ7nY7pTSsfgBx9QFePkDCpeq2Wr8EZr U7bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779211879; x=1779816679; h=content-transfer-encoding:in-reply-to:content-language:from :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=+M43gBW8YyjmiDrGj03/O7lQi+1aZT7Iw8k13I+uBgA=; b=JYEzHWuAQmyc/Px39+a8uFQ4IKo3Paz3bvv0DSzNgmoKV3megbOqPT/euULHDGCrs1 dEGzuwFM8eobN2afYa6GlLIpOTxszZ137TMOgURhPE4DJcn6+0xfNcvzag3KFXNRKYe0 BZMkYpVWeuHcILGwURXcKBetZoBUhycx8GLnXpotr1V4NPJJ+2dm7roGxTLvguJDRaKt 8CFmeiQK7ixTciBJc4pXQIQgFg1+F/5ezMughPLkhAMGiwaFvkqVGR67jl5AyX4U00O0 GHp/c1pJLqz+8bK6QEkLW37fWAn1leuLINcEMBLf2Ltk15ZqNmBc9qZQ+PesAN2Ou8SX BDiQ== X-Forwarded-Encrypted: i=1; AFNElJ8thLOe4QSfrtz6+yjM7uVi7LdkwZz+ZLXOM3t/BbL1sgSu47Qhz5qHdFKNqmoBFes7TeyM2Gdr4gOArYs=@vger.kernel.org X-Gm-Message-State: AOJu0Yz5t3BGvM99UtSmJmtH4fk4GZwtPmv5DeB0TPMCj1paS4Gq2stb EreQRc1XSjJddRIfNiWacYE+dWF1p+eykLosp28yCY+rTzCSgrjscnos+6qMnz8UJNQ= X-Gm-Gg: Acq92OFkdWKpV4xD6/+6NzIW31MIxD0lFsP89AAdz8y4cgO/eZblp4KCRPRqMXycNyW 4RPptsCDV9Re0Tj3fhbBToHbS/xcdC7ZpDWY5cRK/lmmC3fBg5b8gLkdnIrciJ3+9NZjFQCWQc7 DdaTHXWdSOFaay0nN8ocWJrSt78gRjrpXGdds5FnKJX065tZ4oZMydaOUb8eITcOJxzztYbHfld TriuY+BervBoHq3NwnI6TKelq51N3KRtay9Z4pQ7PIICjknWcL2ZrhKpAacuACmw9ijgADD5eIh M58y1Nhd9vxYDHWmrkq444SidO3zJhYhS7ix2VO1rjwOSHpmjukzQLDcxqm7PzsKUjjH5MmIhd5 TR7eQ+auUgvfVQcWdLsNkSIMW0VG3/aNhMl/q5of5JACzizy4qlDF+3l6r25j0lx+O9n0gUOEy2 xQtdToQxrnKz98PLywAYqIXaTiKb0DZcxW5kThTxFyV+e4eg== X-Received: by 2002:a05:6808:4fc8:b0:479:ead7:2a5a with SMTP id 5614622812f47-482e55ffbc1mr12525763b6e.11.1779211879045; Tue, 19 May 2026 10:31:19 -0700 (PDT) Received: from [100.64.0.1] ([165.225.37.83]) by smtp.gmail.com with ESMTPSA id 5614622812f47-482ee0999f3sm6870174b6e.0.2026.05.19.10.31.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 19 May 2026 10:31:18 -0700 (PDT) Message-ID: <59bf4f1e-8d7f-44ff-836b-76b771542e92@sifive.com> Date: Tue, 19 May 2026 12:31:16 -0500 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/2] riscv: track effective hardware PTE A/D updates To: Yunhui Cui Cc: Qingwei Hu , pjw@kernel.org, palmer@dabbelt.com, aou@eecs.berkeley.edu, alex@ghiti.fr, akpm@linux-foundation.org, pasha.tatashin@soleen.com, andrew+kernel@donnellan.id.au, rmclure@linux.ibm.com, debug@rivosinc.com, baolin.wang@linux.alibaba.com, zhangchunyan@iscas.ac.cn, apopple@nvidia.com, namcao@linutronix.de, wangruikang@iscas.ac.cn, apatel@ventanamicro.com, liu.xuemei1@zte.com.cn, ajones@ventanamicro.com, cleger@rivosinc.com, charlie@rivosinc.com, hui.wang@canonical.com, guodong@riscstar.com, pincheng.plct@isrc.iscas.ac.cn, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org References: <20260519031927.70683-1-cuiyunhui@bytedance.com> From: Samuel Holland Content-Language: en-US In-Reply-To: <20260519031927.70683-1-cuiyunhui@bytedance.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Yunhui, On 2026-05-18 10:19 PM, Yunhui Cui wrote: > Separate Svadu capability discovery from the host's effective ADUE > state. Enable SBI FWFT PTE A/D hardware updating on each online CPU > through CPUHP when both Svade and Svadu are present, use the resulting > runtime state for arch_has_hw_pte_young(), and fall back to > software-managed A/D updates when enabling the feature fails. > > Platforms with Svadu but without Svade are treated as always using > hardware PTE A/D updates. Expose the runtime state through an inline > getter so hot MM paths avoid an out-of-line function call. > > Signed-off-by: Yunhui Cui > Reviewed-by: Qingwei Hu > --- > arch/riscv/include/asm/cpufeature.h | 6 +++ > arch/riscv/include/asm/pgtable.h | 8 ++-- > arch/riscv/kernel/cpufeature.c | 73 ++++++++++++++++++++++++++--- > 3 files changed, 77 insertions(+), 10 deletions(-) > > diff --git a/arch/riscv/include/asm/cpufeature.h b/arch/riscv/include/asm/cpufeature.h > index 739fcc84bf7b2..877d71a1ea755 100644 > --- a/arch/riscv/include/asm/cpufeature.h > +++ b/arch/riscv/include/asm/cpufeature.h > @@ -128,6 +128,12 @@ struct riscv_isa_ext_data { > extern const struct riscv_isa_ext_data riscv_isa_ext[]; > extern const size_t riscv_isa_ext_count; > extern bool riscv_isa_fallback; > +extern bool riscv_hw_pte_ad_updating_enabled; > + > +static __always_inline bool riscv_has_hw_pte_ad_updating(void) > +{ > + return READ_ONCE(riscv_hw_pte_ad_updating_enabled); > +} Should this use a static key, since it's only updated at boot, and you mention it is used in MM hot paths? > > unsigned long riscv_isa_extension_base(const unsigned long *isa_bitmap); > static __always_inline bool riscv_cpu_has_extension_likely(int cpu, const unsigned long ext) > diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h > index a1a7c6520a095..20663a466cf6c 100644 > --- a/arch/riscv/include/asm/pgtable.h > +++ b/arch/riscv/include/asm/pgtable.h > @@ -732,14 +732,14 @@ static inline pgprot_t pgprot_writecombine(pgprot_t _prot) > #define pgprot_dmacoherent pgprot_writecombine > > /* > - * Both Svade and Svadu control the hardware behavior when the PTE A/D bits need to be set. By > - * default the M-mode firmware enables the hardware updating scheme when only Svadu is present in > - * DT. > + * Both Svade and Svadu control the hardware behavior when the PTE A/D bits > + * need to be set. The core MM code only cares whether hardware updating of > + * the accessed/dirty state is currently active. > */ > #define arch_has_hw_pte_young arch_has_hw_pte_young > static inline bool arch_has_hw_pte_young(void) > { > - return riscv_has_extension_unlikely(RISCV_ISA_EXT_SVADU); > + return riscv_has_hw_pte_ad_updating(); > } > > /* > diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c > index f46aa5602d74d..e46b2d2b49eed 100644 > --- a/arch/riscv/kernel/cpufeature.c > +++ b/arch/riscv/kernel/cpufeature.c > @@ -35,6 +35,8 @@ > static bool any_cpu_has_zicboz; > static bool any_cpu_has_zicbop; > static bool any_cpu_has_zicbom; > +bool riscv_hw_pte_ad_updating_enabled __read_mostly; > +EXPORT_SYMBOL_GPL(riscv_hw_pte_ad_updating_enabled); > > unsigned long elf_hwcap __read_mostly; > > @@ -287,15 +289,74 @@ static int riscv_ext_zvfbfwma_validate(const struct riscv_isa_ext_data *data, > return -EPROBE_DEFER; > } > > -static int riscv_ext_svadu_validate(const struct riscv_isa_ext_data *data, > - const unsigned long *isa_bitmap) > +static void riscv_set_hw_pte_ad_updating(bool enabled) > +{ > + WRITE_ONCE(riscv_hw_pte_ad_updating_enabled, enabled); > +} > + > +static int riscv_hw_pte_ad_updating_starting(unsigned int cpu) > +{ > + int ret; > + > + ret = sbi_fwft_set(SBI_FWFT_PTE_AD_HW_UPDATING, 1, 0); > + if (ret) { > + if (ret != -EOPNOTSUPP) > + pr_err("CPU%u failed to enable hardware PTE A/D updating: %d\n", > + cpu, ret); > + return ret; > + } > + > + return 0; > +} > + > +static int riscv_hw_pte_ad_updating_dying(unsigned int cpu) > { > - /* SVADE has already been detected, use SVADE only */ > - if (__riscv_isa_extension_available(isa_bitmap, RISCV_ISA_EXT_SVADE)) > - return -EOPNOTSUPP; > + int ret; > + > + ret = sbi_fwft_set(SBI_FWFT_PTE_AD_HW_UPDATING, 0, 0); > + if (ret) > + pr_warn("CPU%u failed to disable hardware PTE A/D updating: %d\n", > + cpu, ret); Why bother disabling the feature when taking a CPU offline? It doesn't create any problems to leave it enabled. Regards, Samuel > + > + return 0; > +} > > +static int __init riscv_hw_pte_ad_updating_init(void) > +{ > + bool has_svade, has_svadu; > + int state; > + > + has_svade = riscv_has_extension_unlikely(RISCV_ISA_EXT_SVADE); > + has_svadu = riscv_has_extension_unlikely(RISCV_ISA_EXT_SVADU); > + > + if (!has_svadu) > + return 0; > + > + if (!has_svade) { > + riscv_set_hw_pte_ad_updating(true); > + pr_info("riscv: hardware PTE A/D updating enabled\n"); > + return 0; > + } > + > + state = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, > + "riscv/pte-ad:starting", > + riscv_hw_pte_ad_updating_starting, > + riscv_hw_pte_ad_updating_dying); > + if (state < 0) { > + pr_info("riscv: leave PTE A/D updates software-managed (%d)\n", > + state); > + return 0; > + } > + > + /* > + * A successful CPUHP_AP_ONLINE_DYN registration means the startup > + * callback has already succeeded on all online CPUs. > + */ > + riscv_set_hw_pte_ad_updating(true); > + pr_info("riscv: hardware PTE A/D updating enabled\n"); > return 0; > } > +arch_initcall(riscv_hw_pte_ad_updating_init); > > static int riscv_cfilp_validate(const struct riscv_isa_ext_data *data, > const unsigned long *isa_bitmap) > @@ -584,7 +645,7 @@ const struct riscv_isa_ext_data riscv_isa_ext[] = { > __RISCV_ISA_EXT_SUPERSET(ssnpm, RISCV_ISA_EXT_SSNPM, riscv_xlinuxenvcfg_exts), > __RISCV_ISA_EXT_DATA(sstc, RISCV_ISA_EXT_SSTC), > __RISCV_ISA_EXT_DATA(svade, RISCV_ISA_EXT_SVADE), > - __RISCV_ISA_EXT_DATA_VALIDATE(svadu, RISCV_ISA_EXT_SVADU, riscv_ext_svadu_validate), > + __RISCV_ISA_EXT_DATA(svadu, RISCV_ISA_EXT_SVADU), > __RISCV_ISA_EXT_DATA(svinval, RISCV_ISA_EXT_SVINVAL), > __RISCV_ISA_EXT_DATA(svnapot, RISCV_ISA_EXT_SVNAPOT), > __RISCV_ISA_EXT_DATA(svpbmt, RISCV_ISA_EXT_SVPBMT),