From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ot1-f51.google.com (mail-ot1-f51.google.com [209.85.210.51]) (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 DA3713DB331 for ; Tue, 19 May 2026 17:34:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.51 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779212089; cv=none; b=b2eOeDUWoZDhyFJiVUaSzxOQ+rl/GwdIr2vmOLxna1588nWtvaEi2a5B8BL3NPGjJAl+F7C5xu0dBA/+WkVYPdYA9QVHM6dvGd0kmZnXvhxhV85JeoeQZ4ocmGc1e6HuH2GoDugovvh3nHhpcuN2MKEgUcpctIhQgG/5fmeupyU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779212089; c=relaxed/simple; bh=JwhGwvSqbQgqXXSZuvhUfDDlYeDiOQOhZ4QkUtAs3Ec=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=BGmfVrsng4BIThuLjG6baxi7sMdBOES8mjsOobFIKaNweAQi/50NU206g/3EG7+as0047QFUgAKr3YMh4z5IQtZ7fTw+3tWBlQS3udqULwmUcnE62RC2ZpxYimbWkADtaWXY60vzcjHHagmw1UXprwOvqbL8ysfG8tO1LA+DjOQ= 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=Z0+ly1W4; arc=none smtp.client-ip=209.85.210.51 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="Z0+ly1W4" Received: by mail-ot1-f51.google.com with SMTP id 46e09a7af769-7df05fc49e5so4050916a34.3 for ; Tue, 19 May 2026 10:34:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; t=1779212087; x=1779816887; 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=tye5Ry/uPh3IdUfjZdOE/qSwu/HkY8CplMa5WQ3odOM=; b=Z0+ly1W4EDCMtq4DhGLkEKhuo5CaBlltWJO6smx8HTYXlCD9++vXhnFVAP9PH5Yk1O D9YJH5cJrqBqIdMFlZEuCSzT6iGZuY6Rys5/NIGNwIMIGHBGVSmfb+8Shl35vAlWcsUm zhwNaFkKyxV9Wc4I+Ne1IUTIkgfT+CZJe/mIHJy1/vghGBSKxUw4UW1wJul/XDGBZD/i Fl6eBef/IQBGJiiBJ5BgZX+H7d5KqAbiWXttSstlzoYF8vgZWnenZ/rxJnexAru0DOZL SDaZizF7M8G8GA16BlJuFdi87WaSWhnpMFFujEySvKjwrnnVPPiI8J/vxtLYSnHgmogk Ju7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779212087; x=1779816887; 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=tye5Ry/uPh3IdUfjZdOE/qSwu/HkY8CplMa5WQ3odOM=; b=LW3yxdsaRUOOWl7Sozx1Rq0PZCKRoV54/sFlX85djM6+lcT2YhTDCVdBGaJYB8KfgG pqxT1RlNDOFAp56uRjHXmOptjkzD2kcLds6W6s0eZRTZgIu9CivAXmnc+JWBTDMDlnQ3 q7HcYUYGwKV2sUymdggpob28+VacNVIDxwwuwW4b7cakgWU4VToH1U7FEmdfbeqKGikw AKKnV8KrnHXnW7RdO7b5Ux/p3Wg3YIS8ydKOen62wduNAPbcIqoV+f9YQvRyrLjljQ+R CsRHkdQkX8XEeC6kBGr4wMqexw1qSEY4USIJSYrWvCrzCerbxhHVycrMgebC6yWkuut9 0fLA== X-Forwarded-Encrypted: i=1; AFNElJ+65OmuR8nbFViv6SWzVFA6t7cvT4E+3/nuNKTz9Pp0h/m3FVyPxOu5qpITxfhyfOQeWSzJXogNL01DDl0=@vger.kernel.org X-Gm-Message-State: AOJu0Yy/xMMkBQhPtVfQSJSkrVoSE8pxAoswILgphqvDyT0h0tQLI3vo mcG/u+rZ468Gmtblw6iSqDe47NNhPUnVPD9sZ4kzxlzG8Uh8bSO//fo3u+G3PPL8Dog= X-Gm-Gg: Acq92OFUZRmdjFyZUWXvWUrl+wENsKGfV9n4jza2ynYJ6vHRPudF422THH7Op+fta7w e69FzngnZcYn5RCqmpZ6eYIpKq0apVQyuDARhaoJmDcB1zgdqHfZCAJu9u0+a1PhrEyh/SUBYCc Yo3TKJGMrsiKlmFE6lpnVW95XnsvIxShI2+DVY9bspxkrxCOz9yQDMb7oxdGTXRnvJ0rzHmN4yQ ko1aPgnLk4HKEOD2zeVskFiJy1okSTkElTTPiRabIoGCPouGUHCrGNLywEFXDyejVRTlFTWIPb4 9so40eZfSrsEiX24YuvRvfbrGwPlc+i4IfEzOongL9F1PoOWN5ZWVWGT8r37HjEkux0ctZi1QSY FDC7ufBUDjpgBHuFBuhnc+UVGvkuXTsglwjmysU70It2xJA1jFXlujarcR8Z2+Oasg2DOrr4ece l/ZMTvxhLePCNeq7pzj6QxCh9/1LjG/qy7DH0= X-Received: by 2002:a05:6830:d0a:b0:7dc:e1e6:7687 with SMTP id 46e09a7af769-7e4ea06dd71mr13897026a34.4.1779212086860; Tue, 19 May 2026 10:34:46 -0700 (PDT) Received: from [100.64.0.1] ([165.225.37.83]) by smtp.gmail.com with ESMTPSA id 46e09a7af769-7e55bc13a0asm11239964a34.21.2026.05.19.10.34.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 19 May 2026 10:34:46 -0700 (PDT) Message-ID: <66c1503a-5fc5-432d-8312-403b2999d9d4@sifive.com> Date: Tue, 19 May 2026 12:34:44 -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: Conor Dooley , Michael Ellerman Cc: Yunhui Cui , 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, Qingwei Hu References: <20260519031927.70683-1-cuiyunhui@bytedance.com> <78e7f039-74a4-4499-a896-a20912ebc6fb@kernel.org> <20260519-justly-fragile-f0e298526b08@spud> From: Samuel Holland Content-Language: en-US In-Reply-To: <20260519-justly-fragile-f0e298526b08@spud> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Conor, On 2026-05-19 10:37 AM, Conor Dooley wrote: > On Tue, May 19, 2026 at 10:05:21PM +1000, Michael Ellerman wrote: >> On 19/5/2026 13:19, 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. >> >> I'm not sure what you mean here. The current code doesn't use an out-of-line >> function call AFAICS? More comments below ... >> >>> 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); >>> +} >>> 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(); >>> } >> >> riscv_has_extension_unlikely() uses an asm alternative, ie. it's patched at >> boot so there's no runtime cost. But now you've changed it to just test a >> bool. >> >> I'm not sure arch_has_hw_pte_young() is a particularly hot path, but seems >> like you could use a static key, so that the code is patched to avoid the >> runtime test? >> >>> 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, >> ... >>> +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; >> >> This block is identical to the tail of the function. I'd probably use "goto >> enable", with an "enable" label below. > > Is this code correct though? On DT systems, !svade && !svadu means we > don't actually know if it is hardware or software managed, so printing > that it's hardware managed may not be correct. > > I don't understand the mm code enough to know if arch_has_hw_pte_young() > returning true is problematic too, but it probably is? This block is for !svade && svadu (Svadu is present; we didn't return above), so I think this block and Michael's comment are correct. Regards, Samuel