While I have generally given a three months cadence to the update, this one is a bit early---mostly due to the upcoming freeze, and many subprojects having reached a point where an update is useful.
Summary ''''''' Achievements Almost full safety for device code; logging and initial work on tracing; starting to look at interoperability of C<->Rust data structures Current blockers Static linking of Rust stdlib; formalize design for QAPI/QMP integration; bump to Rust 1.83 for key safety features Next steps Complete tracing and DMA support; finalize 1.83 update; explore new devices written in Rust and report on holes in bindings Table of contents ''''''''''''''''' * Status in QEMU 10.1 * Build system * Improvements to devices * Cleanups * Next steps Status in QEMU 10.1 ''''''''''''''''''' For platform availability, the only change from 10.0 to 10.1 is that the minimum supported Rust version is now 1.77 rather than 1.63. This means there's no support for building QEMU with Rust enabled with Debian bookworm, *on mips64el* only. Other architectures remain buildable on bookworm too. With the update to Meson 1.8, support for clippy and rustdoc moved from QEMU's meson.build files to Meson itself. The update also made it possible to use --enable-modules and --enable-rust together. There are two new dependencies: anyhow, a commonly used crate providing a general purpose Error implementation; and foreign, a crate that I wrote to provide utilities for conversion between C and Rust data types. Both are used to provide access to ``Error*`` from Rust code. As soon as the Rust version is bumped again from 1.77 to 1.83, Rust devices will need basically no unsafe Rust code. This means that there will be a practical benefit to writing *new* devices in Rust. 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 remain available on platforms without a new-enough compiler version. Build system '''''''''''' Rust is still not enabled by default. The main reason is that Rust staticlibs also link statically to the Rust standard library, thus bloating the resulting executable (and making distros hate us as well). A pending Meson pull request[1] will fix this, as long as ``system/main.c`` is rewritten or wrapped in Rust. As mentioned in the earlier updates, in parallel to QEMU work I'm looking at improvements to Meson's support for Cargo and Rust. While there weren't many news over the last few months, the plan is to add support for cross compilation and the ``[lints]`` section to its Cargo support. I have therefore made a proposal for tighter integration between ``meson.build`` files and Cargo packages[2]. .. [1] https://github.com/mesonbuild/meson/pull/14224 .. [2] https://github.com/mesonbuild/meson/issues/14639 Stefano Garzarella is looking at merging the ``buildigvm`` tool into QEMU's ``contrib/`` directory. ``buildigvm`` is written in Rust, but it has a relatively large set of dependencies that make it impractical (for now) to drive its build from Meson. While for now Stefano is going to call out to Cargo in order to build ``buildigvm``, this is not expected to last forever; ``buildigvm`` will provide a further testbed for changes to Meson. Improvements to devices ''''''''''''''''''''''' New in 10.1 is logging support, as well as ``Error*`` bindings so that ``realize()`` implementations can fail. With the recent merge of a procedural macro for property support, there is basically no remaining unsafe code in devices outside the QOM ``instance_init`` method. Merging the improvements to qdev and VMState however will require a bump of the minimum supported Rust version to 1.83.0. The remaining missing feature for pl011 and HPET is tracing. A student is working on it and he has the simpletrace backend working, with syslog and log coming next. The plan for the dtrace backend is to use the ``probe`` crate[1], possibly extending it to support ust as well. .. [1] https://github.com/cuviper/probe-rs Zhao is looking into using the ``vm-memory`` crate in QEMU. This allows devices to perform DMA, including HPET. Cleanups '''''''' With the Rust bindings and the first couple of devices taking shape, it's time to clean up some of the things that have grown a bit more haphazardly over the last year. One important change, which should make it easier for Kevin to continue his work on block layer bindings, is to split the ``qemu-api`` crate in multiple parts, roughly matching the ``declare_dependency()`` statements used for the C code. Also, pl011 and HPET were developed independently and sometimes have different idioms where we could aim for unification. The main two are: * name of files (the PL011 main source file is ``device.rs``, but the HPET one is ``hpet``.rs) and split between device code and a registers module * adjusting HPET to use the ``bilge`` crate and/or the ``bits`` macro These could be good tasks for someone who is learning Rust. Next steps '''''''''' The highest-priority missing feature, tracing, is being worked on; as is DMA. The next step could be better integration of QAPI/QMP (for which Marc-André Lureau had a prototype already in 2022) and support for QOM properties. Last month we had a discussion on whether to continue with Marc-André's approach of converting between C and Rust representations; implement QEMU's ``Visitor`` interface for Rust data structures; or focus on conversion between ``QObject`` and Rust, using ``serde`` for code generation. Markus leaned towards the latter (though it must be said that there's no code for it yet, and there could be unforeseen obstacles). Finally, I'm going to take a step back from actively writing Rust code for QEMU for some time, but I'll be available for reviews and will keep looking at upstream Meson support for the language. Paolo
