NetBSD 11.0 is out, the nineteenth major release of the project, and the two additions worth your attention are a first class 64-bit RISC-V port and a MICROVM kernel for x86 that boots in roughly ten milliseconds. The RISC-V work covers StarFive JH71xx boards such as the VisionFive 2, the PINE64 STAR64, and QEMU, which means you can try it without buying anything. MICROVM strips the kernel to PVH boot and VirtIO MMIO devices, which is the configuration that makes per request virtual machines plausible. Around those two, the release adds Snapdragon X Elite support, eleven Linux system calls, and layer 2 filtering in npf.
The short answer
NetBSD 11.0 is the nineteenth major release. It adds a 64-bit RISC-V port covering StarFive JH71xx boards, the PINE64 STAR64 and QEMU, plus a MICROVM kernel for x86 that boots in about ten milliseconds using PVH and VirtIO MMIO. Qualcomm Snapdragon X Elite gets initial support with battery, charger, GPIO and I2C drivers on aarch64. The Linux compatibility layer picked up epoll, inotify, clone3, statx and seven more calls. npf gained layer 2 filtering and filtering by user and group, ZFS unlink performance improved, and the release aligns with POSIX.1-2024 and C23.
NetBSD's reputation is portability, and the joke that follows it is that it runs on toasters. The joke undersells what portability buys you when a new architecture shows up. NetBSD 11.0 has a RISC-V port because the tree was built to accept one, and the same release also has a kernel that boots in ten milliseconds because the same layering lets you take almost everything out.
RISC-V, and where to actually try it
The headline addition is a port to 64-bit RISC-V. The named platforms are the StarFive JH71xx family, which covers the VisionFive 2, and the PINE64 STAR64.
QEMU is the third target and the one most readers will use. A first architecture port is a thing you evaluate rather than deploy, and evaluating it in emulation costs you a build and no hardware. What you are looking at is whether the userland you care about compiles and behaves, not whether the board is fast.
Set expectations accordingly. This release supports more than sixty platforms, from machines older than most of the people reading this through to current ARM and x86 hardware, and those older ports carry decades of fixes. A first RISC-V release does not. It is a real port, not a preview, but it is a young one.
The MICROVM kernel is the more interesting engineering
A new MICROVM kernel for x86 boots in around ten milliseconds on 2020 era CPUs. The way it gets there is worth understanding, because the number is a consequence of two decisions rather than a micro optimisation.
First, it boots via PVH. That skips legacy firmware and the whole real mode to protected mode to long mode progression, and hands control to a kernel entry point in a state that is already sane.
Second, its device model is VirtIO MMIO rather than a simulated PCI bus. There is no enumeration to walk, no device tree of emulated legacy hardware to probe. The kernel is told where the devices are.
Ten milliseconds puts the guest kernel below the noise floor of most things you would build around it. If you have evaluated per request or per job virtual machines and concluded the isolation was worth it but the start cost was not, the arithmetic changes when the guest is this cheap to start.
There is a second, smaller virtualization addition: a virt68k port that runs the Motorola 68000 port under QEMU using paravirtualized devices. That one is for the pleasure of it, and it is also a good stress test of how cleanly the device abstractions hold up.
Linux compatibility, and what the list tells you
Eleven system calls landed in compat_linux: epoll, POSIX message queues, statx, readahead, close_range, waitid, renameat2, clone3, sync_file_range, syncfs and inotify.
Read that list as a bug report. epoll and inotify are what every modern daemon, file watcher and event loop reaches for. clone3 is how recent glibc creates threads, which means it is the call that decides whether a binary starts at all. renameat2 is what atomic file replacement uses. statx is the modern stat. These are not exotic interfaces, they are the ones a mainstream Linux binary hits in its first second of life.
The layer is still a compatibility layer, and anything outside the implemented set still fails. But the failures that remain will be more interesting than "it could not create a thread".
Hardware, filesystems and the network stack
Initial Qualcomm Snapdragon X Elite support arrives on aarch64, with drivers for the battery, the charger, GPIO and the I2C controllers. That is the beginning of a laptop story rather than the end of one, and it is the right set of drivers to do first.
On the storage side, ZFS got performance work on rm and unlink, the operation that most reliably makes people notice a filesystem is slow.
On the network side, npf picked up layer 2 filtering and filtering by user and group. The first lets rules act on Ethernet frames before routing, which is what you want on a bridge or a gateway. The second lets a rule follow the identity that owns a socket rather than the address it happens to use, which on a multi user host replaces a pile of per service address workarounds with one line.
The X.Org server gained SIMD accelerated paths on aarch64, and the release aligns with POSIX.1-2024 and C23.
One scheduling note
The project has said that open pullup requests will land on the stable branch after 11.0 and ship as 11.1, expected within roughly two months. The usual advice for a x.0 applies: test it now on machines you can afford to break, and let 11.1 be the one you roll out.
Sources and further reading
- NetBSD 11.0 official release announcement
- The NetBSD Blog: NetBSD 11.0 released
- Phoronix: NetBSD 11.0 released with RISC-V support and enhanced Linux system call compatibility
- NetBSD: recent changes and news
- The NetBSD Project
Frequently asked questions
Which RISC-V hardware does NetBSD 11.0 actually run on?
The port targets 64-bit RISC-V, and the platforms named in the release are the StarFive JH71xx family, which is what powers the VisionFive 2 board, and the PINE64 STAR64. QEMU is supported alongside them, and that is the honest starting point for most people: you can build a RISC-V NetBSD image and boot it in emulation today, without hunting for a board. Treat this as a first port rather than a mature one. It appears in the same release that supports more than sixty platforms in total, and the older ports have decades of polish behind them that a first RISC-V release does not.
What is the MICROVM kernel for, and how is it different from a normal kernel?
It is a stripped x86 kernel built for one job: starting inside a hypervisor as fast as possible. It boots through PVH, which skips the legacy firmware and real mode dance entirely, and it talks to VirtIO MMIO devices rather than probing a full simulated PCI machine. The project reports boots of around ten milliseconds on 2020 era x86 CPUs. That number is what makes a class of designs viable, the ones where a virtual machine is created per request or per job rather than kept warm. If you have looked at microVM based isolation and found the guest side to be the slow part, this is the kernel that addresses it.
Do the new Linux system calls mean NetBSD can run Linux binaries?
NetBSD has had a Linux compatibility layer, compat_linux, for a long time. What 11.0 does is close gaps that modern binaries actually hit: epoll, POSIX message queues, statx, readahead, close_range, waitid, renameat2, clone3, sync_file_range, syncfs and inotify. Look at that list and you can read off what was breaking. epoll and inotify are the ones almost every modern daemon or file watcher reaches for, and clone3 is what recent glibc versions use to create threads. This does not turn NetBSD into a Linux distribution, and anything reaching for a Linux specific kernel interface outside the implemented set will still fail, but the practical hit rate on ordinary userland binaries goes up.
What changed in the npf firewall?
Two additions stand out. npf gained layer 2 filtering, so rules can act on Ethernet level traffic rather than only on IP and above, which matters for bridge and gateway configurations where you want to filter before routing happens. It also gained filtering by user and group, which lets policy follow the identity that owns a socket rather than only the address and port it uses. On a multi user or jail style host that is a meaningfully different way to express a rule set, and it removes a category of workaround built out of separate addresses per service.
Should I upgrade from NetBSD 10.x now or wait?
There is one scheduling detail worth knowing. The project noted that open pullup requests will be committed to the stable branch after 11.0 and become part of 11.1, which is expected within about two months of this release. If you are running production systems on 10.x with no specific need for the new hardware support, waiting for that first point release is the conservative call and always has been with a x.0. If you want the RISC-V port, the MICROVM kernel, Snapdragon X Elite support or the new Linux syscalls, those only exist in 11.0, and testing it now on non critical machines is how the 11.1 fixes get found.