Tags

QAPI patches patches for 2021-09-25

Update to qemu-kvm-6.0.0-13.el9_b.4

Update to qemu-kvm-6.1.0-3.el9

Update to qemu-kvm-6.0.0-13.el9_b.3

Update to qemu-kvm-4.2.0-29.module+el8.2.1+12598+39ddf37a.9

Update to qemu-kvm-5.2.0-16.module+el8.4.0+12596+209e4022.10

Update to qemu-kvm-6.0.0-30.module+el8.5.0+12586+476da3e1

QAPI patches patches for 2021-09-13

Update to qemu-kvm-6.1.0-2.el9

Update to qemu-kvm-6.0.0-13.el9_b.2

Update to qemu-kvm-5.2.0-16.module+el8.4.0+12532+c27b1004.9

Rust binding for QAPI and qemu-ga QMP handler examples

Hi,

Among the QEMU developers, there is a desire to use Rust. (see previous
thread from Stefan "Why QEMU should move from C to Rust", the rust-vmm
related projects and other experiments).

Thanks to our QAPI type system and the associate code generator, it is possible
to create Rust bindings for the generated C types (also called FFI binding) and
functions (rust-bindgen could probably do a similar job, but it is unnecessary
given the FFI generator is quite straightforward).

More interesting (but more complicated) is to expose a Rust API, and provide
convenient conversions FFI<->Rust. Taking inspiration from glib-rs binding, I
implemented a simplified version of the FromGlib/ToGlib traits, with simpler
ownership model, sufficient for QAPI needs.

The usage is as such:

- from_qemu_none(ptr: *const sys::P) -> T
  Return a Rust type T for a const ffi pointer P.

- from_qemu_full(ptr: *mut sys::P) -> T
  Return a Rust type T for a ffi pointer P, taking ownership.

- T::to_qemu_none() -> Stash<P>
  Returns a borrowed ffi pointer P (using a Stash to destroy "glue"
  storage data, if any).

- T::to_qemu_full() -> P
  Returns a ffi pointer P. (P resources are leaked/passed to C/ffi)

With the Rust QAPI bindings, we can implement QMP callbacks in idiomatic Rust.
With the translation traits, we can also bind manually more types and implement
other functions (QOM is my next target).

Since Rust doesn't cover all the platforms QEMU supports (see first patch and
https://doc.rust-lang.org/nightly/rustc/platform-support.html), the Rust code
should be optional. Nevertheless, it is desirable to write sensitive code in
Rust first, and a C version if the code/feature is not optional and not specific
to a platform where Rust is Tier-1 or 2.

v3 (RFC):
 - rebased (was waiting for qapi 'if' conditions to be merged)
 - now covers the various QEMU QAPI schemas (QEMU schema is left out of this
   series, but test schema is the complete)
 - numerous improvements, patch reorgnisation, cleanups etc

v2 (PoC):
 - split the original patch in smaller patches and more digestable form
 - dropped the DBus interface experiment from this series
 - various build-sys improvements, new configure options --with-rust(-target)
 - various attempts at better meson integration, finally satisfied enough with the
   current solution, which handles getting link flags from Rust sanely.
   (more meson stuff to come to handle config-host/features mapping etc).
 - rebased, QGA QMP now uses unions, added support for it.
 - start a common crate (which re-surfaced issues with foreign types and traits,
   worked around with a NewPtr wrapper)
 - explicit errors when ifcond are presents (after various unsucessful attempts,
   I will try to tackle it in v3)
 - mingw cross compilation support
 - some attempts to add it to CI
 - actually implement {get,set}-vcpus
 - vendor the external crates

Fixed update

QAPI patches patches for 2021-09-03

Update to qemu-kvm-6.1.0-1.el9

Update to qemu-kvm-6.0.0-13.el9

Error reporting patches for 2021-08-26

QAPI patches patches for 2021-08-26