mbox series

[0/2] target/riscv: ISA string conversion fix and enhancement

Message ID cover.1650777360.git.research_trasio@irq.a4lg.com (mailing list archive)
Headers show
Series target/riscv: ISA string conversion fix and enhancement | expand

Message

Tsukasa OI April 24, 2022, 5:22 a.m. UTC
Hello,

There is two issues related to RISC-V ISA extension string
I want to be fixed before QEMU 7.1 release.



Issue 1 (workaround in PATCH 1):

Related: <https://lists.gnu.org/archive/html/qemu-devel/2022-03/msg03726.html>

Generating long ISA extension string is definately a good thing to merge.
However, it includes two extensions with possibly invalid order:

-   Zhinx (IEEE754 binary16 arithmetic in GPR)
-   Zhinxmin (subset of Zhinx, conversion only)

This is because:

1.  Z* extensions are ordered with the second character by closely
    related extension category list
    (RISC-V ISA Manual draft: IMAFDQLCBKJTPV)
2.  ... but it doesn't have the character "H" yet

I raised this issue on RISC-V ISA Manual GitHub and being discussed:
<https://github.com/riscv/riscv-isa-manual/issues/837>

Considering software compatibility, "H" is likely placed after "V" (and
"N").  I kept single-letter "H" based on this assumption.

However, Zhinx and Zhinxmin extensions are not that important because
it's incompatible with F and D.  That's why I proposing to remove those
from ISA extension string generation for now.  If "H"-extension ordering
is determined, we can safely add Zhinx* extensions again.

Note that this patch does not remove extensions.  It just disables
putting Zhinx* extensions in a DeviceTree entry ("riscv,isa").

Of course, we can alternatively move Zhinx and Zhinxmin
before "Svinval" but after "Zve64f", assuming "H" comes after "V".
Let me know which might be better.



Issue 2 (fixed in PATCH 2):

Some operating systems does not correctly parse ISA extension string with
version numbers and multi-letter extensions.

On Linux, 5.18 is the first version to implement safe parser.
However, old Linux kernels are still confused by ISA extension strings
(generated by QEMU >= 7.1) containing multi-letter extensions.
Much worse, those multi-letter extensions are enabled by default:

1.  Zba
2.  Zbb
3.  Zbc
4.  Zbs

For instance, existence of "Zbc" can cause problems if we disable
compressed instructions ("C" extension).

As I searched through, I found this kind of issue on following OSes:

-   Linux (kernel version 5.17 or earlier)
-   FreeBSD (at least 14.0-CURRENT)
-   OpenBSD (at least current development version)

I propose a new CPU option "short-isa-string" (default: false), which
disables generating ISA extension string with multi-letter extensions.

Example:
    qemu-system-riscv64 ... \
        -cpu rv64,h=on,svnapot=on,svinval=on,short-isa-string=on \
        ...
    Without "short-isa-string=on", QEMU generates DeviceTree with
    following ISA extension string:
        rv64imafdch_zba_zbb_zbc_zbs_svinval_svnapot
    With it, QEMU generates following ISA extension string:
        rv64imafdch




Tsukasa OI (2):
  target/riscv: Tentatively remove Zhinx* from ISA extension string
  target/riscv: Add short-isa-string option

 target/riscv/cpu.c | 7 ++++---
 target/riscv/cpu.h | 2 ++
 2 files changed, 6 insertions(+), 3 deletions(-)


base-commit: 754f756cc4c6d9d14b7230c62b5bb20f9d655888