Re: [PATCH v2 3/5] riscv: support early isa ext and use it to optimize pgtable_l4|l5_enabled

[Conor Dooley]

On Wed, Sep 09, 2026 at 07:46:49AM +0800, Jisheng Zhang wrote:
> > > This assumes SV48 and SV57 are the only "early" users, but
> > > other ISA ext may also need "early", who knows. So if future some extensions
> > > need the "early", the code is ready, the author doesn't need to care about
> > > the isa filling at all.
> > > 
> > > So I prefer my patch as is. What's your opinion?
> > 
> > We're about decade into the port being merged and this is the only thing
> 
> but the isa extension alternative is not, it was introduced by me three
> years ago. But no matter how many years, 
> 
> > behaving in this way. I don't think the code in this patch is worth it on
> > the off chance that something else comes along. If it does, we can
> 
> this makes sense. Let me cook a new version
> 
> > always fish this implementation back up and use it.
> 
> > 
> > I'd also like to differentiate this code from "needing early", because
> > this is about populating the information early in the extension bitmap,
> > rather than about actually needing the information. There's no advantage
> 
> the code after arch/riscv/mm/init.c but before mmu on needs the
> bitmap informaion when pgtable_l5|l4_enabled() is called (w/o
> USE_EARLY_PGTABLE_LEVELS)

Oh, I must have missed something then, I didn't realise you were
patching the alternatives early - I thought you were skipping them until
the information became available at the normal time. Sorry bout that.

How bad is the damage btw, if you implement pgtable_l5_enabled() as

static __always_inline bool pgtable_l5_enabled(void)
{
	if (riscv_has_extension_likely(RISCV_ISA_EXT_SV57))
		return true;

	return _pgtable_l5_enabled;
}

? It shouldn't be too bad since it should get expanded to stuff like

	if (riscv_has_extension_likely(RISCV_ISA_EXT_SV57) || _pgtable_l5_enabled)

by the compiler. I wonder if you can do this and get rid of
USE_EARLY_PGTABLE_LEVELS entirely, since the unpatched alternative
should return false?

Cheers,
Conor.

(btw, I am kinda unavailable til the 22nd, so sorry if I take some time
to reply here or to a new revision)

> 
> > gained, as far as I can tell, by setting this early and it only makes
> > the code more complicated.
> > 
>

Attachment: signature.asc
Description: PGP signature