Re: [PATCH 00/33] First Rust update for QEMU 10.2

[Paolo Bonzini <pbonzini@redhat.com>]

On 9/11/25 12:04, Peter Maydell wrote:
> On Mon, 8 Sept 2025 at 11:53, Paolo Bonzini <pbonzini@redhat.com> wrote:
>>
>> This includes:
>> - bumping MSRV to 1.83.0 to support const_refs_to_static
>> - Zhao's safe, builder-based implementation of migration callbacks
>> - Manos's qdev properties macro.  While bit-based properties are
>>    not yet supported, that's a small change overall.
>> - the Rust crate split from Marc-André
>> - adding proc macro aliases in individual crates, also from Marc-André
>>
>> I'm still not convinced about having "bql" depend on "migration",
>> but I am convinced by the crate split between "util" and "bql",
>> so we can move the implementation of VMState from "bql" to
>> "migration" later if needed.
>>
>> For the purpose of getting this in as an easy-to-use base for future
>> development, I'm disabling CI from Debian and Ubuntu.  The plan is:
>> - that Debian will require trixie to enable Rust usage
>> - that Ubuntu will backport 1.83 to its 22.04 and 24.04 versions
>>    (https://bugs.launchpad.net/ubuntu/+source/rustc-1.83/+bug/2120318)
>> - that Marc-André or someone else will add Rust to other CI jobs
> 
> How far into the future does moving to 1.83.0 push our
> "we can enable rust and make it mandatory" point? I was
> hoping we would be able to do that sometime soon but this
> sounds like we're going to be still a long way out from that :-(
Sorry for not seeing the question, the good news is that it doesn't push 
it by much, if at all.  Debian bookworm has even updated rustc-web last 
month to 1.85.0 (say thanks to Firefox), so the only remaining straggler 
is Ubuntu and they're working on it.

As far as technical blockers go, Marc-André has a couple fixes pending 
in Meson, and of course tracing support is still in flight.  But we 
could enable it for 10.2 in CI and 11.0 in configure.

The bad news is that enabling Rust by default is a bit like a point of 
no return and, in that respect, other factors may matter more than 
distro support:

* Community support: it's a lot of new code to deal with, and we're not 
Linux.

* What's the killer app: DMA support may take a bit longer, so right now 
Rust is limited to very simple devices for which memory safety is not a 
primary issue.  Could it be BQL-free interrupts, where even simpler 
devices like interrupt controllers could benefit from a more picky compiler?

* Dependency on Meson work: this is something that Zhao and I didn't 
have time to go through, but right now adding a Rust device is *a lot* 
more verbose than adding the corresponding Rust device.  For day to day 
work it's not a huge deal, as the verbosity is a minor issue while we 
have a handful of Rust devices.  Furthermore, I have plans to improve 
Meson in that respect, so that it understands more of the Rust 
conventions, and we've already structured a lot of the Rust code with an 
eye towards those future versions of Meson.  The problem is that for the 
most part of 2026 we'll be bumping the minimum supported *Meson* version 
relatively quickly.  Right now we only bump it for --enable-rust, but 
the picture changes if Rust is enabled by default or even hard-required.

Let's talk about it on the community call, since we didn't make it at 
QEMU Summit.

Paolo