Summary ''''''' Achievements Further improved code structure; initial bindings for QAPI merged; IOMMU support complete in rust-vmm; Rust enabled in CI for more host operating systems; dtrace support
Ongoing work for 11.0 Mostly work on the Meson side to finish Cargo integration Future work QMP commands; GStreamer backend; enable by default? Table of contents ''''''''''''''''' * Status in QEMU 11.0 * Improvements and cleanups * Other work in progress * Next steps Status in QEMU 11.0 ''''''''''''''''''' The project is still experimental but is taking a more definite shape. Some new code is waiting for review, but most of the effort over the last few months was in consolidating what we have. The minimum supported Rust version is fixed at 1.83, supported on all platforms except Debian bookworm mips64el. In particular Ubuntu LTS is now packaging the version of Rust that is required. Together with fixes to Meson bugs, which were released in version 1.10, all targets can now enable Rust in CI. Meson 1.10 also makes it possible to use rustc to link emulator binaries, which makes the resulting executable smaller and the build system a bit simpler. Support for tracing with the ``dtrace`` crate is now available through the ``probe`` crate. For ``ust``, the plan is to deprecate it, though no step in that direction has been taken. UST is able to work with probes placed by the ``dtrace`` backend. 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; in the meanwhile, 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 ''''''''''''''''''''''''' Migration support was improved to support thread-safe (non-BQL) devices, and Zhao looked at how to make HPET BQL-free, as is the case for the C version. This work was stopped, at least temporarily, because we found some deadlocks... and discovered that the C code is simply not taking a required lock. :/ More work, not tied to adoption of Rust, is needed to understand what help is needed from common code in order to avoid deadlocks between the BQL and device-specific locks. However, the same HPET device is already using these same migration improvements to achieve compatibility with the C device's migration format, despite very different organization of the code. Version 10.2 split the Rust<->C bridges across multiple crates, each linking to the corresponding C code; this is now extended to bindgen-generated code. 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 Meson language extensions are now finalized and were approved by Meson's BDFL. For more information: - https://github.com/mesonbuild/meson/issues/14639 (specification) - https://github.com/mesonbuild/meson/pull/15223 (implementation) - https://gitlab.com/bonzini/libblkio/-/commit/b14230d59 (using it in libblkio) Other work in progress '''''''''''''''''''''' Marc-André tried using Rust to develop a GStreamer backend for the audio subsystem. His prototype is available at https://lore.kernel.org/qemu-devel/[email protected]/. Martin Kletzander has started to look at using pin-init to replace the unsafe implementation of instance_init. It's notable that Rust itself is considering several solutions to this problem, and tracking it as an "experiment" (https://github.com/rust-lang/lang-team/issues/336). The two top contenders are - init expressions (https://hackmd.io/@aliceryhl/BJutRcPblx), directly based on pin-init - &out references (https://hackmd.io/awB-GOYJRlua9Cuc0a3G-Q) Personally I'd put my vote on the latter, which has the advantage of better lifetime tracking. Anyway, this is very early and for now we will have to use macros to emulate the native language support. Kevin Wolf had posted some work on the block layer last year. Improvements to the build system since then probably would simplify some parts of it. While there are no Rust summer of code projects planned this year, there are still a few days left to propose them (the deadline is February 7th). Next steps '''''''''' ``vm-memory`` integration Last year, Zhao 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 was now released, and work on ``vm-memory`` integration can continue. Improving Meson support for cross-compiling Rust Orthogonally to the Cargo work, I looked at adding Meson support for build-machine subprojects. Right now, each subproject needs to declare whether it builds host- or build-machine targets. The changes at https://github.com/mesonbuild/meson/pull/15404 allow a procedural macro crate, depending for example on itertools, to request that the dependency be built for the build machine. Integration of QObject and QAPI with serde The first step is under review and is mostly ready. Future work includes modular builds (splitting bindings across multiple source files or even crates, to reduce the cost of recompilation), support for QMP commands, and support for QOM properties. I2C support This was posted on the list and is on its way towards being updated, posted and integrated in QEMU. With it, a third device (a GPIO expander) was converted to Rust.
