On Mon, Sep 15, 2025 at 04:27:47PM +0200, Paolo Bonzini wrote: > On 9/11/25 12:04, Peter Maydell wrote: > > On Mon, 8 Sept 2025 at 11:53, Paolo Bonzini <pbonz...@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.
That is true, but we're already seeing alot of stuff that is directly adjacent to QEMU that is written in Rust, with some overlaps amongst contributors. Coconut SVSM, IGVM, Rust VMM, virtiofsd, libbkio, and more besides. So if we consider community as "open source virtualization devs" it looks like there is a reasonable pool of talent with experience that can cross-pollinate with QEMU. > * 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? I suggest we don't try to over-think this too much, as it'll become a bit of a chicken and egg problem. IMHO initial ideas for Rust usage will inevitable be fairly simple, as that's part of the learning process for all of us, avoiding trying to bite off too much too quickly. As a result, the initial work will not look very compelling The more worthwhile and substantial things will only arrive once use of Rust in QEMU has had time to marinate, and at least some of them will be things we can't thing of ahead of time. "if you build it, they will come" Even if QEMU doesn't mandate Rust directly, Rust is already a part of QEMU indirectly, so on the distro front the point of no return is pretty much already here unless you want to cut out an increasing number of interesting features. eg we see ourselves integrating with libblkio, and igvm, both of which we do via C shims around the Rust code. There are more of such things to come - a Rust impl of the EDK vars storage is probable, there are virtee crates for dealing with low level SEV pieces that have been proposed before and seem interesting. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
