[RFC PATCH 0/1] About adding new Z extensions in ISA realization

[Conor Dooley]

Hey Ruinland!

On Tue, Dec 20, 2022 at 12:02:35PM +0000, Ruinland Tsai wrote:
> Dear all,
> I am wondering about what is the policy on adding new multilettered
> extensions into the ISA realization mechanism ?

There's already been a few added, so it's largely a case of
rinse-and-repeat?

> Currently we have plenty ratified exntensions left un-added, and some
> of them are already being used frequently

Which in-the-wild SoCs actually have support for the unsupported
extensions, out of curiosity? It'd be nice to have one with zbb support
at the very least.

> such as the B extension
> family - - namely, the zba, zbb, zbc, and zbs.

Heiko has been working on incorporating zbb support here:
https://lore.kernel.org/linux-riscv/20221130225614.1594256-1-heiko@sntech.de/#t

The first half of this patchset is likely to be applied immediately
after -rc1. That half has been split out and is here:
https://lore.kernel.org/all/20221207180821.2479987-1-heiko@sntech.de/

Clearly though that's trying to use zbb in the kernel so is not quite
the same as what you are doing here with just adding them to the various
structs.

There was another patchset in June (ignore my & Samuel's confusion about
ordering, that's been resolved since) that added some HWCAP stuff for a
superset of the extensions you've mentioned here:
https://lore.kernel.org/linux-riscv/YqY0i22SdbHjB%2FMX@Sun/
That'd need a rebase to apply on current code anyway (and I'd prefer if
my patches cleaning up the ordering in those structs got applied before
we add more extensions "out of order" to them!)

There's also been discussion about whether it is sustainable to keep
adding stuff to hwcap like this, but I have not been able to find the
particular ML posts for that. Palmer spun up a PoC for a syscall & Heiko
has said he would look into following up on that work after the inital
zbb stuff was ready.

The Higher Powers^TM will have to comment on what the policy is with
adding more extensions in the interim. I'll admit it is a bit odd to
not at least inform userspace as to what the actual ISA is.
Heiko or Palmer, perhaps you've got a better idea of what the craic is
there?

> Being unsure about whether I have done it in the right way, hence I
> wrote this RFC for adding those extensions.
> 
> Also, just as I have inquired on the list before, what about the vendor
> extensions?

Since you didn't link the previous questions, I dunno what they were,
but...

After the discussion at the Plumbers BoF, the policy about vendor
behaviour has been changed. The new wording is:
<quote>
Additionally, the RISC-V specification allows implementers to create
their own custom extensions.  These custom extensions aren't required
to go through any review or ratification process by the RISC-V
Foundation.  To avoid the maintenance complexity and potential
performance impact of adding kernel code for implementor-specific
RISC-V extensions, we'll only consider patches for extensions that either:

- Have been officially frozen or ratified by the RISC-V Foundation, or
- Have been implemented in hardware that is widely available, per standard
  Linux practice.
<\quote>

> If a vendor wants to submit a vendor extensions without
> reavealing the detailed sepcs, what will be examined ?

I can only imagine that this would vary completely depending on what
that extension is doing? I'm not sure how you would expect anyone to be
able to review something though if you do not provide any information?

Unless the answer is "no vendor extensions without specs", this sounds
like something that could only be answered once code is available.

Not the answers you were looking for perhaps Ruinland, but hopefully I
was at least somewhat helpful.

Thanks,
Conor.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-riscv/attachments/20221220/58747052/attachment.sig>