[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[PATCH 0/2] target/riscv: ISA string conversion fix and enhancement
From: |
Tsukasa OI |
Subject: |
[PATCH 0/2] target/riscv: ISA string conversion fix and enhancement |
Date: |
Sun, 24 Apr 2022 14:22:34 +0900 |
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
--
2.32.0
- [PATCH 0/2] target/riscv: ISA string conversion fix and enhancement,
Tsukasa OI <=