QEMU, a popular open-source machine emulator and virtualizer, has officially released version 10.2 (following a four-release candidate cycle) as the second point update to the 10.x series.

A notable change is a clarification of QEMU’s security policy. The project now explicitly defines which machine types fall under the “virtualization use case” when determining what qualifies as a security bug.

Several legacy components have been removed. The long-deprecated -old-param option is gone, and the Arm PXA CPU family has been fully removed.

It's been a rocky few days for Arm

Spectre V1 mitigations in the Linux kernel are coming for RISC-V with newer RISC-V core designs being vulnerable to Spectre Variant One style attacks.

Spectre V1 as a reminder is the variant for Bounds Check Bypass with CPU speculative execution in conditional branches. The Linux kernel RISC-V code hasn't seen Spectre V1 protections since earlier more basic RISC-V core designs have been immune to Variant One and other Spectre vulnerabilities. But newer more complex RISC-V core designs are bringing some of the same challenges exhibited on x86_64 and AArch64 architectures.

LILYGO has introduced the T-Display P4, a handheld development board built around Espressif’s ESP32-P4 application processor and a companion ESP32-C6 for wireless connectivity. The platform targets portable HMIs, sensor-equipped field devices, and edge systems that require a display, camera support, and multiple radios in a compact enclosure.

Measuring about 63 × 109 × 22 mm, the T-Display P4 is built around the ESP32-P4, which combines a dual-core RISC-V CPU running at up to 360–400 MHz with an additional low-power RISC-V core operating at 40 MHz

The RISC-V CPU architecture changes have been merged for the in-development Linux 6.19 kernel.

With this new kernel RISC-V now supports CPU hot-plugging in parallel for secondary CPU cores. Secondary CPU cores can now be brought up asynchronously with the "HOTPLUG_PARALLEL" kernel feature now being supported on RISC-V for more quickly bringing up multiple CPU cores besides the primary CPU0. The CPU hot-plugging support particularly with RISC-V SoCs is primarily about dynamic enabling/disabling of CPU cores while the system is running rather than needing to handle their bring-up sequentially.

The set of six branches containing SoC and platform updates/additions for the Linux 6.19 kernel have been merged for enabling a lot of new RISC-V and ARM 64-bit hardware as well as enhancing some existing SoCs/platforms.

Arnd Bergmann sent out all of the SoC updates/additions on Friday for the ongoing Linux 6.19 merge window. There is some exciting new hardware, Device Trees for some new ARM machines, and more

An interesting anecdote from this week's batch of RISC-V fixes for the Linux 6.18 kernel exposed that the MIPS RISC-V/JEDEC vendor ID was wrong for code merged at the start of the kernel cycle. The testing hadn't caught it either as the QEMU emulation also ended up inadvertently using the wrong vendor ID too.

Canonical has been bullish on RISC-V with Ubuntu being one of the most common Linux distributions endorsed by RISC-V board vendors. Canonical also has been bullish on the Flutter toolkit for crafting their desktop installer UI and other modern UI/app interfaces. But these two together haven't panned out with Flutter not currently supporting RISC-V. Canonical has submitted pull requests now for enabling RISC-V support with Flutter.

The lack of RISC-V support by Flutter has been a known issue to Ubuntu engineers for a while now. Canonical engineer Valentin Haudiquet has been working on getting Flutter on RISC-V. A Flutter pull request this week seeks to upstream support for the Flutter tool on RISC-V. Another patch adds the RISC-V 64-bit desktop Linux engine support so that you can cross-compile a Flutter engine for RISC-V Linux from x86_64 Linux hosts.

Following the mainline Linux kernel support for the VisionFive 2 RISC-V single board computer from StarFive, Linux kernel patches are on the way for their new VisionFive 2 Lite low-cost offering. With the StarFive VisionFive 2 Lite this RISC-V board can be procured for as little as $19.9 USD as one of the cheapest yet fairly capable RISC-V SBCs.

The VisionFive 2 Lite is a recently crowd-funded effort from StarFive Tech with the cheapest 2GB version costing just $19.9+ USD while 4GB of RAM and WiFi will cost $30+ and 8GB with WiFi at $37+.

RISC-V is an industry standard, like USB or Wi-Fi. The specifications are publicly available under the Creative Commons license and every engineer, wherever they are in the world, can use them to design their products locally, while engaging with the global RISC-V ecosystem.

This standard is defined by RISC-V International and its members. Decisions are voted upon collectively, ensuring every member is heard. It’s a model that has worked for us for many years, ensuring any updates to the RISC-V ISA happen transparently, without breaking existing designs, and always in service of the broader ecosystem.

The RISC-V ISA is already an industry standard and the next step is impartial recognition from a trusted international organization.

Today, I’m excited to announce that we have taken that first step. RISC-V International has been approved as a recognized PAS (that’s publicly available specification) Submitter by the ISO/IEC Joint Technical Committee (JTC 1).

This means we’re able to submit draft international papers, starting with the The RISC-V Instruction Set Manual, for consideration as true, international standards.

One of the more unexpected talks at last week's Ubuntu Summit 25.10 in London was by Antonio Salvemini of Bolt Graphics, who introduced the company's forthcoming range of Zeus graphics accelerator hardware. These are very unlike any conventional GPUs – or indeed anything else.

[…]

Bolt's Zeus hardware will use an entirely different model, and we found it refreshing that the company's How it works page doesn't mention the dreaded initialism "AI" once. These accelerators are aimed at producing graphics using a specific rendering method called path tracing.

[…] Path tracing is a step further on from simple ray tracing. A few decades ago, ray tracing was a favorite way to demonstrate high-resolution, multi-color computer graphics, taking hours to days to render scenes of shiny spheres.

As Salvemini put it: "The problem with ray tracing is that each light wave only bounces one way. In path tracing, they can bounce anywhere, and you randomly select just some of these paths to display." Thus, Monte Carlo path tracing (MCPT) – as described in this 2024 UCSD computer graphics lecture [PDF] – uses Monte Carlo simulation, as invented by John von Neumann and Stanislaw Ulam during World War II.

Inspired by Easy 6502 by Nick Morgan, this is a quick-ish introductory tutorial to RISC-V assembly programming. This tutorial is intended for those with a basic familiarity with low level computer science concepts, but unfamiliar with RISC-V. If you’re curious about RISC-V, I hope this will be a good start to your journey to learning about it.

Are there any currently available RISC-V dev boards that support the H extension for running KVM?

In the last article, we covered bare metal programming on RISC-V. Please familiarize yourself with that material before proceeding with the rest of this article, as this article is a direct continuation of the aforementioned one.

This time we are talking about RISC-V SBI (Supervisor Binary Interface), with OpenSBI as the example. We’ll look at how SBI can assist us with implementing operating system kernel primitives and we’ll end the article with a practical example using riscv64 virt machine.

Merged for Mesa 25.3 is adding the necessary device information bits for more supported and unsupported GPU cores. This includes some additional PowerVR Series 6XE, 6XT, 8XE, and B-Series GPUs. This complements the PVR driver currently being focused on the A-Series AXE-1-16M and the B-Series BXS-4-64 / BXM-4-64 GPU IP.

The newly-added documentation for the open-source PVR driver explains:

The following hardware is unsupported and not under active development:

========= =========== ==============

Product Series B.V.N.C

========= =========== ==============

GX6250 Series 6XT 4.45.2.58

GX6650 Series 6XT 4.46.6.62

G6110 Series 6XE 5.9.1.46

GE8300 Series 8XE 22.68.54.30

GE8300 Series 8XE 22.102.54.38

BXE-2-32 B-Series 36.29.52.182

BXE-4-32 B-Series 36.50.54.182

========= =========== ==============

Device info and firmware_ have been made available for these devices, typically due to community requests or interest, but no support is guaranteed beyond this.

The MIPS I8500 features a scalable multithreaded architecture with 4 threads per core and support for multi-cluster deployments, enabling up to 24 threads per cluster. It delivers ultra-low-latency, deterministic data movement with integrated security, ideal for orchestrating packet flows across accelerators and enabling intelligent communication between compute blocks, humans, and networks. Its energy-efficient design ensures optimal performance for edge AI workloads, while RVA23 profile readiness and support for Linux and Real-Time operating systems ensures software portability and ecosystem alignment.

Linus Torvalds has come out strong against proposed support for RISC-V big endian capabilities within the Linux kernel.

In response to a mailing list comment whether RISC-V big endian "BE" patches being worked on would be able to make it for this current Linux kernel cycle. Linus Torvalds initially wrote:

"Oh Christ. Is somebody seriously working on BE support in 2025?

WHY?

Seriously, that sounds like just stupid. Is there some actual real reason for this, or is it more of the "RISC-V is used in academic design classes and so people just want to do endianness for academic reasons"?

Because I'd be more than happy to just draw a line in the sand and say "New endianness problems are somebody ELSES problem", and tell people to stop being silly.

Let's not complicate things for no good reason. And there is NO reason to add new endianness.

RISC-V is enough of a mess with the millions of silly configuration issues already. Don't make it even worse.

Tell people to just talk to their therapists instead. That's much more productive."