Re: [PATCH v2 00/16] rust: QObject and QAPI bindings

On 2/23/26 10:53, Daniel P. Berrangé wrote:
> On Thu, Jan 08, 2026 at 02:10:27PM +0100, Paolo Bonzini wrote:
>> This adds two related parts of the Rust bindings:
>>
>> - QAPI code generator that creates Rust structs from the JSON
>>    description.  The structs are *not* ABI compatible with the
>>    C ones, instead they use native Rust data types.
>>
>> - QObject bindings and (de)serialization support, which can be used to
>>    convert QObjects to and from QAPI structs.
>>
>> Unfortunately Rust code is not able to use visitors, other than by
>> creating an intermediate QObject.  This is because of the different
>> architecture of serde vs. QAPI visitors, and because visitor's
>> dual-purpose functions, where the same function is used by both input and
>> output visitors, rely heavily on the structs using the same representation
>> as the visitor arguments (for example NUL-terminated strings).
>>
>> The serde format implementation was co-authored by me and Marc-André.
>> Marc-André did all the bug fixing and integration testing.
>>
>> As an example of how this would be used, the marshaling functions for
>> QMP commands would look like this:
> 
> Can you give more of the big picture about what follows this ?  From
> this example you're showing, are you suggesting that you'll be soon
> moving QMP command impls from C to Rust ?

The reasons for Marc-André and I to do this was just as an exploration. 
The patches show a different way to do what he had already tackled in 
2022, and allow a direct comparison the relative benefits between a more 
Rust-focused approach and a more direct translation of QEMU's C code.

Marc-André indeed had command implementations in Rust and that would be 
an obvious next step to continue on the QAPI side.  On the other hand, 
the QObject part (without QAPI structs) also works as a step towards 
more QOM integration, especially with respect to properties and 
backends.  Having a full-blown QObject implementation to move around 
bools is perhaps over-engineered, but is also an easy way to make a 
generic implementation that works for all QAPI types.

The block layer also needs QAPI for option parsing, so Kevin's work on 
block layer bindings would also benefit from having this integration.

In other words, there is no real big picture from me other than "someone 
needs to do the hard part for others": QOM, QAPI and the build system 
are the three central components from which all other bindings branch 
out.  Zhao and Marc-André have helped a lot with this work, and they 
also showed how to use these hard parts (see Zhao's vm-memory work and 
Marc-André's GStreamer backend), now it's also time for others to try 
and to take inspiration from Rust for improving the C side of things.

Paolo

> 
>>
>> fn qmp_marshal_query_stats(args: *mut QDict,
>>      retp: *mut *mut QObject, errp: *mut *mut Error)
>> {
>>      let qobj = unsafe { QObject::cloned_from_raw(args.cast()) };
>>
>>      let result = from_qobject::<StatsFilter>(qobj)
>>           .map_err(anyhow::Error::from)
>>           .and_then(qmp_query_stats)
>>           .and_then(|ret| to_qobject::<Vec<StatsResult>>(ret).map_err(anyhow::Error::from));
>>
>>      match qmp_marshal_query_stats_rs(qobj) {
>>          Ok(ret) => unsafe { *retp = ret.into_raw(); },
>>          Err(e) => unsafe { crate::Error::from(e).propagate(errp) },
>>      }
>> }
>>
> 
> With regards,
> Daniel