linux-kernel - Re: [PATCH v5 1/4] RISC-V: Add Svade and Svadu Extensions Support

Open Source and information security mailing list archives

Message-ID: <ed87b4d8-1a74-4d9a-9beb-296db1f12043@ghiti.fr>
Date: Fri, 21 Jun 2024 10:06:58 +0200
From: Alexandre Ghiti <alex@...ti.fr>
To: Conor Dooley <conor.dooley@...rochip.com>
Cc: Yong-Xuan Wang <yongxuan.wang@...ive.com>, linux-kernel@...r.kernel.org,
 linux-riscv@...ts.infradead.org, kvm-riscv@...ts.infradead.org,
 kvm@...r.kernel.org, apatel@...tanamicro.com, ajones@...tanamicro.com,
 greentime.hu@...ive.com, vincent.chen@...ive.com,
 Jinyu Tang <tjytimi@....com>, Paul Walmsley <paul.walmsley@...ive.com>,
 Palmer Dabbelt <palmer@...belt.com>, Albert Ou <aou@...s.berkeley.edu>,
 Anup Patel <anup@...infault.org>,
 Mayuresh Chitale <mchitale@...tanamicro.com>,
 Atish Patra <atishp@...osinc.com>, wchen <waylingii@...il.com>,
 Samuel Ortiz <sameo@...osinc.com>, Clément Léger
 <cleger@...osinc.com>, Evan Green <evan@...osinc.com>,
 Xiao Wang <xiao.w.wang@...el.com>, Alexandre Ghiti <alexghiti@...osinc.com>,
 Andrew Morton <akpm@...ux-foundation.org>,
 "Mike Rapoport (IBM)" <rppt@...nel.org>,
 Kemeng Shi <shikemeng@...weicloud.com>,
 Samuel Holland <samuel.holland@...ive.com>,
 Jisheng Zhang <jszhang@...nel.org>, Charlie Jenkins <charlie@...osinc.com>,
 "Matthew Wilcox (Oracle)" <willy@...radead.org>,
 Leonardo Bras <leobras@...hat.com>
Subject: Re: [PATCH v5 1/4] RISC-V: Add Svade and Svadu Extensions Support

Hi Conor,

On 21/06/2024 10:01, Conor Dooley wrote:
> On Fri, Jun 21, 2024 at 09:52:01AM +0200, Alexandre Ghiti wrote:
>> On 05/06/2024 14:15, Yong-Xuan Wang wrote:
>>> Svade and Svadu extensions represent two schemes for managing the PTE A/D
>>> +/*
>>> + * 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.
>>> + */
>>> +#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) &&
>>> +	       !riscv_has_extension_likely(RISCV_ISA_EXT_SVADE);
>>> +}
>>
>> AFAIK, the riscv_has_extension_*() macros will use the content of the
>> riscv,isa string. So this works fine for now with the description you
>> provided in the cover letter, as long as we don't have the FWFT SBI
>> extension. I'm wondering if we should not make sure it works when FWFT lands
>> because I'm pretty sure we will forget about this.
>>
>> So I think we should check the availability of SBI FWFT and use some global
>> variable that tells if svadu is enabled or not instead of this check.
> No. If FWFT stuff arrives, it should be plumbed into exactly the same
> interface. "Users" should not have to think about where the extension is
> probed from and be able to use the same interface regardless.
>
> The interfaces we have have already caused some confusion, we should not
> make them worse.

Understood, we need to keep that in mind then.

>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@...ts.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives