Table of Contents
Published: 2026-09-21 · Category: RISC-V Development · Reading time: ~5 min · Status: DRAFT
What landed on the list
On 20 September 2026, Guodong Xu posted [PATCH v8 00/11] riscv: hwprobe: Expose RVA23U64 base behavior to LKML. The cover letter heads an eleven-patch series — the eighth revision, which tells you this has been through real review rather than being a first post.
The series does three separable things: it teaches the kernel about a new ISA extension (Zic64b), it builds the machinery to describe which ISA "base" a machine implements, and it hangs a single rva23u64 answer off the hwprobe syscall. All three matter if you ship software to heterogeneous RISC-V hardware and currently parse /proc/cpuinfo to decide what you can run.
The eleven patches, as posted
| # | Subject | Layer |
|---|---|---|
| 01 | riscv: Add B to hwcap and hwprobe | Feature reporting |
| 02 | dt-bindings: riscv: Require block-size for Zicbom | DT contract |
| 03 | dt-bindings: riscv: Add Zic64b extension description | DT contract |
| 04 | riscv: Add Zic64b to cpufeature and hwprobe | Kernel + ABI |
| 05 | riscv: dts: spacemit: k3: Add Zic64b ISA extension | SpacemiT K3 |
| 06 | riscv: dts: spacemit: k1: Add Zic64b ISA extension | SpacemiT K1 |
| 07 | riscv: dts: sophgo: sg2044: Add Zic64b ISA extension | Sophgo SG2044 |
| 08 | riscv: Add a getter for user PMLEN support | Pointer masking |
| 09 | riscv: cpufeature: Introduce ISA bases bitmap | Kernel |
| 10 | riscv: cpu: Output isa bases lines in cpuinfo | Observability |
| 11 | riscv: hwprobe: Introduce rva23u64 base behavior | Userspace ABI |
Why the device-tree half is the load-bearing part
Patches 02 and 03 are easy to skim past and are arguably the most consequential. Patch 02 requires a block size to be declared for Zicbom, and patch 03 adds the Zic64b binding. Cache-block management operations (Zicbom zero/management/prefetch family) are useless to software unless something authoritative states the block size — a driver that guesses wrong invalidates the wrong range.
Patch 04 then surfaces Zic64b through cpufeature (kernel-internal) and hwprobe (userspace-visible). The three DTS patches add the property to SpacemiT K1, SpacemiT K3 and Sophgo SG2044.
One honesty note: the extension name Zic64b denotes a 64-byte cache-block declaration, and that reading is consistent with patch 02 pairing it with a mandatory Zicbom block size. That semantic gloss is our inference from the patch structure, not a sentence quoted from the cover letter. Verify against the ISA specification before you design around it.
The real prize: one syscall answer for "is this RVA23?"
Patches 09, 10 and 11 are the part that changes how portable software is written.
- 09 introduces an ISA bases bitmap in
cpufeature. - 10 prints "isa bases" lines in
/proc/cpuinfo, so humans and scripts can see it. - 11 exposes a
rva23u64base behaviour throughhwprobe.
hwprobe is the syscall RISC-V added so userspace can ask the kernel about the machine instead of parsing text. Today, a runtime that wants to know whether it may use RVA23 baseline features has to enumerate individual extension bits and reconstruct the profile itself — which is exactly the kind of logic that rots. A single base-behaviour key collapses that to one query.
Patch 01 (add "B", the bit-manipulation extension, to hwcap and hwprobe) is the same story at single-extension granularity. Patch 08 (a getter for user PMLEN support) does it for pointer masking, which is relevant to tagged-pointer runtimes and hardware-assisted sanitizers.
What this means if you target K1, K3 or SG2044
Three of these parts are already shipping in volume — the K1 is in SBCs and the CM4-adjacent modules, the K3 is the RVA23 follow-on, and the SG2044 is a many-core server part. Getting their cache-block and ISA-base descriptions into the upstream device trees is what makes a single distro image viable across all three rather than three images with three kernels.
For a build or deploy pipeline, the practical sequence is:
- Stop parsing
/proc/cpuinfoextension strings in application code. Once patch 11 lands,hwprobeis the contract. - If you ship a BSP with a downstream K1/K3 device tree, watch patches 05–07 — an upstream DTS that adds
Zic64bwill need to be reconciled with yours. - Pin your expectation to the merge, not the posting. v8 is under review, not merged.
Not disclosed / not established
- Target kernel release. No merge commit or maintainer pull is referenced. Do not plan a product around a version number.
- Whether the series will be taken as-is. Revision eight means prior rounds produced change requests.
- Benchmark or performance impact of the Zic64b reporting — none is claimed in the subjects.
Sources
- LKML archive, 20 Sep 2026 —
[PATCH v8 00/11] riscv: hwprobe: Expose RVA23U64 base behaviorand patches 01/11–11/11, Guodong Xu: <http://lkml.org/lkml/2026/9/20> - Same-day related RISC-V traffic on the same list:
[PATCH RFC 0/3] riscv: Add explicit die-level CPU topology(Troy Mitchell);[PATCH v2 2/3] riscv: use generic MMIO accessors(Qingfang Deng);[PATCH 1/1] riscv: dts: spacemit: set ETH MAC from eeprom for OrangePi(Chukun Pan)
Verification notes
- Date is from the LKML date index, not from a search-engine snippet;
freshnessfilters have repeatedly returned stale results in past cycles. - The patch list is transcribed from the archive, including order and version markers. Patch 03 appeared before 01 in the raw list; the table above is re-sorted by index.
- Zic64b semantics are inference, flagged inline above.
- No claim is made about merge status, target release, or performance.