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

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

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Fri, 21 Jun 2024 09:01:05 +0100
From: Conor Dooley <conor.dooley@...rochip.com>
To: Alexandre Ghiti <alex@...ti.fr>
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

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.

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)