RustInQemu: Difference between revisions

From QEMU
 
(9 intermediate revisions by 2 users not shown)
Line 15: Line 15:


* <code>[RFC v3 00/32] Rust binding for QAPI and qemu-ga QMP handler examples</code><br />[https://patchew.org/QEMU/20210907121943.3498701-1-marcandre.lureau@redhat.com/ on patchew] [https://lore.kernel.org/qemu-devel/20210907121943.3498701-1-marcandre.lureau@redhat.com/ on lore]
* <code>[RFC v3 00/32] Rust binding for QAPI and qemu-ga QMP handler examples</code><br />[https://patchew.org/QEMU/20210907121943.3498701-1-marcandre.lureau@redhat.com/ on patchew] [https://lore.kernel.org/qemu-devel/20210907121943.3498701-1-marcandre.lureau@redhat.com/ on lore]
== Minimum supported versions ==
Required versions:
* 1.59.0 has const <tt>CStr::from_bytes_with_nul_unchecked</tt>, not really possible to go below that. Of the supported distributions only Debian bullseye has an older version.
* 1.63.0 is available on Debian bookworm (though it also rustc-web, which is 1.70.0 on mips64el and 1.78.0 on all other platforms).
* 1.75.0 is available on Ubuntu 22.04 and 24.04.  It can return "impl Trait" in traits. This is important when using the pinned_init crate in traits (e.g. to implement QOM instance_init).
* 1.83.0 will allow const_refs_statics and nested offset_of (useful to make vmstate type-safe).
Bindgen 0.60.x has --allowlist-file. Of the supported distributions only Ubuntu 22.04 has an older version (0.59.x).


== Work in progress ==
== Work in progress ==
=== Paolo ===
=== Paolo ===
* To be merged: finish QOM, MemoryRegion
* Posted: Opaque<> (to split crates and also first step for annotated pinning)
* Planned: errno, chardev
* Planned: chardev
* Later: pinned_init
* Later: pinned_init... maybe use MaybeUninit as a first step?
* Upstream Meson support for rustdoc and "objects:"
* Upstream Meson: "objects:", rustdoc, <tt>-C prefer-dynamic</tt>


=== Manos ===
=== Manos ===
* Documentation
* Documentation
=== Zhao ===
* HPET live migration.


=== Kevin ===
=== Kevin ===
* Executing async code
* Executing async code, block driver implementations
* Block driver implementations
** https://lore.kernel.org/qemu-devel/20250211214328.640374-1-kwolf@redhat.com/
 
=== Zhao ===
* hpet timer device
** timer/gpio/memattrs bindings


== TODO ==
== TODO ==
Line 58: Line 48:
* rustfmt currently requires nightly, decide what to do about it
* rustfmt currently requires nightly, decide what to do about it
* Place rustdoc output for master somewhere?
* Place rustdoc output for master somewhere?
* split qemu_api into multiple crates
* more QOM procedural macros
* more QOM procedural macros
** generate qdev properties?
** generate qdev properties
** generate parts of TypeInfo?
** generate parts of TypeInfo?
* distros need dynamically linked libstd (rewrite system/main.c in Rust, or [https://github.com/mesonbuild/meson/issues/14215 do it in Meson]?)
** monomorphization of <tt>T: IsA&lt;Class&gt;</tt> to <tt>&T</tt> (like the momo crate)
* distros need dynamically linked libstd
** rewrite all main()s in Rust and use [https://github.com/mesonbuild/meson/issues/14224 -C prefer-dynamic]?
** or should Meson be able to link C programs with rlibs?


=== New code to write===
=== New code to write===
* feature parity for pl011
* feature parity for pl011
* safe object creation with [https://docs.rs/pinned-init/ pinned_init, originating from Linux])
* safe object creation with [https://docs.rs/pinned-init/ pinned_init, originating from Linux])
* complete vmstate bindings
* Generic Rust<->C interop, Error (https://github.com/bonzini/rust-qemu)
* Generic Rust<->C interop, Error (https://github.com/bonzini/rust-qemu)
* DMA (investigate vm-memory?)
* DMA (investigate vm-memory?)
Line 80: Line 75:
=== Miscellanea  ===
=== Miscellanea  ===


- <code>qemu-bridge-helper.c</code> Re-write SUID C executable with useful features.
* <code>qemu-bridge-helper.c</code> Re-write SUID C executable with useful features.
 
=== Bindings ===


* visitors/QOM properties, could be interesting for <code>hw/sensor/tmp105.c</code>...
=== Devices  ===
=== Devices  ===


* <code>hw/block/pflash_cfi01.c</code>, <code>hw/block/pflash_cfi02.c</code> (claimed, WIP)
* <code>hw/block/pflash_cfi01.c</code>, <code>hw/block/pflash_cfi02.c</code> (claimed, WIP)
** needs block bindings
** needs block bindings
* <code>hw/timer/hpet.c, hw/timer/i8254.c</code> (claimed, WIP)
* <code>hw/timer/i8254.c</code> (claimed, WIP)
** needs timer/memattrs/bitops/error/irq/trace bindgings
* <code>hw/mem/nvdimm.c</code> (suggested by [[User:Manos|Manos]])
* <code>hw/mem/nvdimm.c</code> (suggested by [[User:Manos|Manos]])


[[Category:RustInQemu]]
[[Category:RustInQemu]]

Latest revision as of 14:12, 27 February 2025

For the old RustInQemu page, see RustInQemu/2022

Active effort


Past efforts

  • [RFC v3 00/32] Rust binding for QAPI and qemu-ga QMP handler examples
    on patchew on lore

Work in progress

Paolo

  • Posted: Opaque<> (to split crates and also first step for annotated pinning)
  • Planned: chardev
  • Later: pinned_init... maybe use MaybeUninit as a first step?
  • Upstream Meson: "objects:", rustdoc, -C prefer-dynamic

Manos

  • Documentation

Zhao

  • HPET live migration.

Kevin

TODO

Bugs

Nice things to have

  • run doctests with meson test
  • Remove need for manual "meson subprojects update --reset" when updating packagefiles/
  • Improve tool integration
    • Run code checks a la "meson test --suite codecheck"? (clippy and rustfmt)
  • rustfmt currently requires nightly, decide what to do about it
  • Place rustdoc output for master somewhere?
  • split qemu_api into multiple crates
  • more QOM procedural macros
    • generate qdev properties
    • generate parts of TypeInfo?
    • monomorphization of T: IsA<Class> to &T (like the momo crate)
  • distros need dynamically linked libstd
    • rewrite all main()s in Rust and use -C prefer-dynamic?
    • or should Meson be able to link C programs with rlibs?

New code to write

Ideas for lints without breaking CI

See https://github.com/bonzini/rust-qemu/commit/95b25f7c5f4e2694a85a5503050cc98da7562c7c

  • run clippy as part of "make check", possibly only if Rust is newer than some version (1.74.0 so that clippy can be configured in Cargo.toml?)
  • deny many individual lints, do not deny groups (complexity, perf, style, suspicious) on regular builds. allow unknown_lints.
  • add to CI a fallible job that runs on nightly clippy with -Dclippy::complexity -Dclippy::perf -Dclippy::suspicious -Dclippy::style -Dunknown_lints. the job should generally pass, and if a new lint triggers it probably should be added to Cargo.toml as either "allow" (rare) or "deny" (possibly after adding #[allow()] to the source).

Possible project targets

Miscellanea

  • qemu-bridge-helper.c Re-write SUID C executable with useful features.

Bindings

  • visitors/QOM properties, could be interesting for hw/sensor/tmp105.c...

Devices

  • hw/block/pflash_cfi01.c, hw/block/pflash_cfi02.c (claimed, WIP)
    • needs block bindings
  • hw/timer/i8254.c (claimed, WIP)
  • hw/mem/nvdimm.c (suggested by Manos)