Conveners
RISC-V MC
- ATISH PATRA (Rivos)
- Bjรถrn Tรถpel (Rivos, Inc.)
- Palmer Dabbelt (Google)
Description
Weโd like to propose bringing back the RISC-V Microconference at Linux Plumbers 2025. As the RISC-V ecosystem continues to grow, so does the importance of having a space where developers, hardware vendors, toolchain maintainers, and distro folks can come together to solve real-world problems. This microconference has always been a great venue for open, technical discussions that help move RISC-V Linux support forward โ from core architecture work to platform enablement and userspace coordination. In general, anything that touches both Linux and RISC-V is fair game, but the conversation often centers around a few common themes we have been following:
Supporting new RISC-V ISA features in Linux, especially vendor-specific or upcoming standardized extensions
Enabling RISC-V-based SoCs, which often involves working across various Linux subsystems in addition to the core arch/riscv code
Coordinating with distributions and toolchains to ensure consistent and correct userspace-visible behavior
Possible Topics
Itโs still early to lock down a full agenda, but a number of topics have been circulating on the various mailing lists lately are:
The issues with WARL discovery
Why CFI is not merged yet (if not merged by then)
ACPI enablement progress and remaining gaps (e.g ACPI WDAT watchdog)
How to handle RVA profiles in Linux kernel ?
QoS
Key Stakeholders
Sorry if I missed anyone, but hereโs a quick list of folks whoโve regularly shown up and helped keep the conversation moving at past RISC-V MC:
RISC-V contributors: Palmer, Atish, Anup, Conor, Sunil, Charlie, Bjorn, Alex, Clรฉment, Andrew, Deepak โ and probably a few more Iโm forgetting.
SoC folks: Arnd, Conor, Heiko, Emil, Drew โ with more SoC families bringing up RISC-V support, this group keeps expanding.
Weโve also consistently had great input from contributors across other architectures like arm, arm64, ppc, mips, and loongarch. Since we all end up touching shared code (especially in areas like drivers or platform support), these cross-arch discussions have been super valuable โ and we expect even more of that this year as shared SoC platforms become more common.
Accomplishments post 2024 Microconference
Ftrace improvements [1]
System MSI support [2]
RIMT patches available on lore[3]
CFI series is at v17 [4]
[1] https://lore.kernel.org/linux-riscv/174890236299.925497.5731685320676689356.git-patchwork-notify@kernel.org/#r
[2] https://lore.kernel.org/linux-riscv/20250611062238.636753-13-apatel@ventanamicro.com/
[3] https://lore.kernel.org/linux-riscv/20250610104641.700940-1-sunilvl@ventanamicro.com/
[4] https://lore.kernel.org/linux-riscv/20250604-v5_user_cfi_series-v17-0-4565c2cf869f@rivosinc.com/#r
A RISC-V ISA has a lot of variables, and the ISA string describes a small subset of those variables, so some of the remaining ones are current discovered by directly interacting with the ISA implementation through trial and error (WARL).
WARL hinders virtualization as the discovery is done through registers that we don't want to trap and emulate for performance reasons, and there is no...
Itโs the elephant in the room: in the Linux kernel, RV64 has become significantly more popular and better supported than its smaller sibling โ the RISC-V 32-bit platform.
There have been multiple open discussions about dropping RISC-V 32 support to "liberate" kernel development.
However - - and itโs a big however - - many people actively use RISC-V 32 Linux in production, and some of...
QoS Background
Some of the next generation of RISC-V SoCs are expected to have QoS (Quality-of Service) functionality to control and monitor the usage of resources such as cache capacity and memory bandwidth. The RISC-V Quality-of-Service Identifiers (Ssqosid) extension [1] adds the srmcfg CSR to configure a hart with two identifiers: a Resource Control ID (RCID)...
Upstreaming kernel support traditionally happens only after silicon becomes available, but this approach often delays software enablement and ecosystem readiness. For the first time in the RISC-V world, we are tackling the challenge of pre-silicon kernel upstreamingโenabling Linux kernel features ahead of actual chip availability.
In this session, we will share the methodology, toolchains,...
Background
When we bring up a RISC-V board from a chipset vendor, the kernel log cannot give us enough details about what happens inside the kernel. Kernel logs do not contain sufficient debugging information. Because of this, a vmcore is necessary to understand what is really happening inside the kernel.
For binary analysis, many Linux developers use the vmcore file. They usually enable...