Rust in QEMU update, October 2025

Rust in QEMU update, October 2025

[Paolo Bonzini]

Summary
'''''''

Achievements
  Definitive code structure and MSRV bump; migration improvements and
  tracing merged; Rust enabled in CI for more host operating systems;
  initial bindings for QAPI and QMP

Ongoing work for 10.2
  Integrate Meson bugfixes from upcoming version 1.9.2; IOMMU support
  ongoing in rust-vmm

Future work
  More QAPI/QMP integration; enable by default; tighter integration
  between Meson and Cargo


Table of contents
'''''''''''''''''

* Status in QEMU 10.2
* Improvements and cleanups
* Other work in progress
* Next steps


Status in QEMU 10.2
'''''''''''''''''''

While the project is still in a "pupal" state, a lot of the individual
bits are less experimental, and the overall structure of the Rust code
in QEMU is clearer.

The minimum supported Rust version is now 1.83, with no extra bumps
planned.  The only unsupported platforms are Debian bookworm mips64el
(other architectures remain buildable on bookworm too) and Ubuntu
LTS releases, for which newer versions of Rust are planned but not
available yet.

We have enabled Rust in CI in almost all jobs.  Once some Meson bugs
are fixed, which currently prevent enabling Rust for Windows and macOS,
all targets should support Rust.  Both Marc-André Lureau and Martin
Kletzander have already identified and fixed some bugs in Meson, and
their patches will be included in Meson 1.9.2.  Meson 1.9.2 version
will also make it possible to use rustc to link emulator binaries, which
makes the resulting executable smaller and the build system a bit simpler.

Over the sunmer, Tanish Desai wrote most of the code for tracing support;
it is now merged as well, closing the biggest feature gap between Rust
and C versions of the devices.  While support for the ``dtrace`` and
``ust`` backends is still missing, ``dtrace`` should be added soon via
the existing ``probe`` crate.  For ``ust``, the plan is to deprecate it.

With these improvements, there is already a practical benefit to writing
*new* devices in Rust, especially if you don't need other APIs than those
with bindings.  The build system boilerplate is still substantial
for the time being, but this is a temporary issue and the existing
pl011 and HPET devices provide a model that is easy to follow.

If any devices are contributed that are written in Rust and do not have
a C counterpart, it may be worth splitting "enable Rust" from "enable
all devices written in Rust".  This way, the C versions of the pl011
and HPET devices can remain available until all platforms have a new-enough
compiler version and no build system issues.


Improvements and cleanups
'''''''''''''''''''''''''

With the recent merge of ``VMStateDescriptionBuilder``, there is no
remaining need for unsafe code in devices, outside the QOM ``instance_init``
method.

Migration support was also improved to support thread-safe (non-BQL)
devices.  The plan is to apply these improvements to HPET, which recently
became BQL-free in C.  Thread-safety may also be a good reason to rewrite
other simple devices from C to Rust, for example interrupt controllers.

Rust<->C interoperability is now split across multiple crates, each
linking to the corresponding C code.  This should simplify work on block
devices, as there is no need anymore to build the support code twice
for tools and emulators, and it also makes documentation less daunting.

In addition, GLib bindings use glib_sys, which makes it possible to use
only features present in our minimum supported version of glib (2.66).

There are now a lot fewer loose ends in the ``meson.build`` files.  The
files are still pretty large, but they are homogeneous and should be
readable.

Zhao Liu is looking into cleaning up HPET to separate the registers
struct, as is already the case for PL011, and at the same time enable
lock-free MMIO.


Other work in progress
''''''''''''''''''''''

``vm-memory`` integration
  Zhao also looked into using the ``vm-memory`` crate in QEMU.  Because of
  QEMU's support for IOMMUs, this required changes to the crate.  Hanna
  Czenczek's work on IOMMU support for rust-vmm is very close to being
  merged, and we'll wait for that before continuing with ``vm-memory``
  integration in QEMU.

  Nevertheless Zhao's work provided some insights on what the future API
  could look like---for example, a memory store in safe Rust could look
  like this::

     ADDRESS_SPACE_MEMORY.store::<Le32>(addr, 42);


Meson support for Cargo
  As mentioned in the earlier updates, in parallel to QEMU work I'm
  looking at improvements to Meson's support for Cargo and Rust.

  The thrust for these improvements is to let QEMU use Cargo subprojects
  for the crates it depends upon, making it possible to add dependencies
  simply by adding them to ``Cargo.lock`` (the file that is currently
  sitting in the ``rust/`` subdirectory).  Hanna was particularly vocal
  in requesting an easier process to add new Rust dependencies. :)

  Meson 1.10 will already be able to read a superproject's ``Cargo.lock``,
  but later on it will also need support for reading QEMU's ``Cargo.toml``.
  This has two objectives: first to resolve the set of features that are
  required from the dependencies, and second to enable adding new simple
  build targets (e.g. devices and tests) with one or two lines of Meson
  code.  The first parts of the work are at:

  - https://github.com/mesonbuild/meson/issues/14639 (specification)

  - https://github.com/mesonbuild/meson/pull/15069 (first part of the
    implementation, covering feature resolution)

  This is longer term work.  I'm seeking to have it merged over
  the next few Meson releases starting with Meson 1.10, but it does
  not block further work on QEMU.  Right now we have roughly 20
  dependencies, and we're adding about 1 per month on average.


Next steps
''''''''''

There is almost feature parity between C and Rust devices, other than
for the following items:

- dtrace support [Stefan]

- lock-free MMIO in HPET [Zhao]

Once the above are fixed and Ubuntu gets Rust 1.83, QEMU can enable
Rust usage by default.

Integration of QObject and QAPI with serde is on the mailing list.
It enables QMP integration and it also helps supporting QOM properties,
but is not planned for QEMU 10.2 since there are no users yet.
One possibility is to resurrect more of Marc-André's 2022 work
on QMP commands, for which he used qemu-ga.

The cleanups to the build system should be enough to restart work
on the block layer.

More hands would be welcome in adding bindings for more backends
and bus types, for example (respectively) block devices and I2C.