One of the ideas behind RISC-V is that not everyone needs the same CPU. The architecture reserves explicit encoding space for instructions that sit outside the base ISA and the ratified extensions, exactly so chip designers can add their own. On 22 June 2026, Jon Taylor published a walkthrough on Canonical’s blog covering how that kind of hardware fits with Ubuntu and where the limits are.
A custom instruction is one a chip designer adds beyond what the standard defines. The reasons are usually specific: accelerating cryptographic operations in embedded security, custom DSP work for audio (the example cited is Espressif’s ESP32-P4 SIMD DSP), custom data types for machine learning with a better performance-per-watt ratio, or driving external accelerators more directly than memory-mapped peripherals allow.
What you need on Ubuntu comes down to one technical distinction: whether the instruction adds processor state or not.
Stateless: PPAs and nothing else
When an instruction only processes data and adds no registers or state the operating system has to preserve, you don’t touch the OS at all. The recommended workflow leans on Ubuntu’s Launchpad infrastructure. You ship precompiled libraries or a custom toolchain through PPAs (Private Package Archives), build your application against that toolchain, and that’s it. The payoff is that you keep getting security and maintenance patches from Canonical for the rest of the system, on top of the performance you gain from the customised hardware.
Stateful: your own kernel, and you maintain it
The harder case is instructions that do add processor state. Here the OS has to save and restore that state across context switches, so you need a custom kernel. Canonical provides an “image cookbook” to build one, alongside the custom toolchain and user-space applications in PPAs.
The warning is blunt and worth reading first: that custom kernel is not maintained by Canonical. Security updates and patches are on you. Packages from the standard repositories stay supported, but the modified kernel falls outside that guarantee.
Runtime detection with hwprobe
The other practical piece is portability. If you build binaries that assume a particular extension and then run them on hardware that lacks it, you hit an illegal-instruction trap. Canonical’s recommendation is to use hwprobe, which lets user-level code ask the kernel which extensions the hardware it’s running on actually supports.
With that information you can fall back instead of failing: for instance, reaching for a soft floating-point implementation when the corresponding unit isn’t present. That’s the sensible pattern for shipping software meant to run across a varied family of RISC-V chips rather than a single model.
If you work with custom RISC-V silicon, the split is clear. If your instruction holds no state, stay in user space with PPAs and keep every guarantee. If it does, you take on the kernel and its upkeep. Either way, detecting capabilities at runtime before using them saves you from surprises when you swap boards.
Source
Based on How to use RISC-V custom instructions with Ubuntu, published by Jon Taylor on Canonical’s blog on 22 June 2026.