riscv: improve parsing of riscv,isa property strings

[mhorne]

Summary

This code was originally written under the assumption that the ISA
string would only contain single-letter extensions. The RISC-V
specification has extended its description of the format quite a bit,
allowing for much longer ISA strings containing multi-letter extension
names.

Newer versions of QEMU (7.1.0) will append to the riscv,isa property
indicating the presence of multi-letter standard extensions such as
Zfencei. This triggers a KASSERT about the expected length of the
string, preventing boot.

Increase the size of the isa array significantly, and teach the code
to parse multi-letter extensions, and optional extension version
numbers. We currently ignore them completely, but this will change in
the future as we start supporting supervisor-level extensions.

[jrtc27]

The underscore isn't required before the first multi-character extension, and in fact the canonical form drops it (e.g. rv64iafdcxcheri, what we use for CheriBSD, is valid).

[jrtc27]

i.e. probably this should also stop at [sxz] to handle the multi-letter extensions, though there's a wrinkle that older QEMU bogusly treated S and U as single-letter extensions indicating the presence of those modes. Linux has a hack to spot that specific case (if -1 isn't _ and +1 is u).

[mhorne]

In D36601#830972, @jrtc27 wrote:

The underscore isn't required before the first multi-character extension, and in fact the canonical form drops it (e.g. rv64iafdcxcheri, what we use for CheriBSD, is valid).

Okay, where can one learn the exact rules for how this ISA string is to be formatted? The device tree document Bindings/riscv/cpus.yaml is notably lacking in detail here.

[jrtc27]

In D36601#830974, @mhorne wrote:

In D36601#830972, @jrtc27 wrote:

The underscore isn't required before the first multi-character extension, and in fact the canonical form drops it (e.g. rv64iafdcxcheri, what we use for CheriBSD, is valid).

Okay, where can one learn the exact rules for how this ISA string is to be formatted? The device tree document Bindings/riscv/cpus.yaml is notably lacking in detail here.

It's as defined in the RISC-V unprivileged spec

[mhorne]

In D36601#830976, @jrtc27 wrote:

In D36601#830974, @mhorne wrote:

In D36601#830972, @jrtc27 wrote:

The underscore isn't required before the first multi-character extension, and in fact the canonical form drops it (e.g. rv64iafdcxcheri, what we use for CheriBSD, is valid).

Okay, where can one learn the exact rules for how this ISA string is to be formatted? The device tree document Bindings/riscv/cpus.yaml is notably lacking in detail here.

It's as defined in the RISC-V unprivileged spec

Thank you, I had not kept up with these changes. I'll update with a more robust solution.

[mhorne]

Rework the parsing logic to match the ISA string specification. Handle
multi-letter extensions by walking over them completely; same goes for version
numbers. I have tried to sketch this out in a way that anticipates future
changes.

Avoid dynamically allocating space for isa, but bump its size significantly.
We don't currently call fill_elf_hwcap() very early, but I believe that
eventually we may need to, in order to obtain information about relevant
extensions before pmap_bootstrap() (for example, svpbmt), or other early
initialization actions.

[jrtc27]

sys/riscv/riscv/identcpu.c

207–208

FPE-less builds need to parse these just not update hwcap

[mhorne]

sys/riscv/riscv/identcpu.c

207–208

Yes, they will be skipped over by the default case then. Same with p, h, v as they are now.

[mhorne]

Any further feedback? I intend to commit this sometime before the end of the week.