RVA23, ratified by RISC-V International in October 2024, defines the mandatory extension baseline for application-class RISC-V. Eighteen months on, is the profile real inside the software stack? This talk answers from one vantage point — the Linux kernel — through a shipping part.

SpacemiT's K3 is the first mass-produced RVA23 SoC. Bringing it up in mainline (RISCstar with SpacemiT), we found the kernel's RVA23 mandatory coverage stuck near 68% for a year, with bindings missing several extensions. Over several revisions those gaps closed, and Linux v7.0 reached 100%.

From that experience, I examine how the community decides what "supporting" an extension means: a data-backed classification by whether an extension adds architectural state the OS must save and restore — showing roughly two-thirds are stateless and only need to be discoverable, not implemented. This explains the principles maintainers apply.

I then cover two complementary halves now in review for v7.1.

1) Runtime detection: a unified series, carried forward from Andrew Jones' (Qualcomm) RFC, resolving rva23u64/rva23s64 base behaviour and exporting it via /proc/cpuinfo and hwprobe.

2) Compile-time specialisation, presented by co-speaker Charlie Jenkins (Meta), builds the kernel for RVA23. I share review feedback — including Paul Walmsley's call for hardware measurements — answered with numbers from the K3.

Complete mainline RVA23 lets distributions ship generic images and reduce fragmentation; Ubuntu 26.04 has adopted it while Debian, Fedora and Red Hat wait.