Brian Cain <quic_bc...@quicinc.com> writes: > On 10/7/2024 2:15 PM, Paolo Bonzini wrote: > > Il lun 7 ott 2024, 19:56 Brian Cain <quic_bc...@quicinc.com> ha scritto: > > On 10/7/2024 6:03 AM, Paolo Bonzini wrote: > > The following changes since commit > b5ab62b3c0050612c7f9b0b4baeb44ebab42775a: > > > > Merge tag 'for-upstream' of https://gitlab.com/bonzini/qemu into > staging (2024-10-04 19:28:37 +0100) > > > > are available in the Git repository at: > > > > https://gitlab.com/bonzini/qemu.git tags/for-upstream > > > > for you to fetch changes up to dec4b629fc17fedcd2172066071f99ec8dcc8d8d: > > > > meson: ensure -mcx16 is passed when detecting ATOMIC128 (2024-10-07 > 13:01:06 +0200) > > > > ---------------------------------------------------------------- > > * first commit for Rust support > > Aside: Paolo, thanks for your work here! > > Thanks to Manos, I am just the shepherd. :) > > So far I think the focus for Rust support has been on device models. But is > there any interest in > being able to write TCG plugins in Rust > > Is there a good degree of ABI compatibility across QEMU versions? If so, > plugins are external shared libraries and > therefore they could be built (with Cargo) independent of any QEMU code. > > I am not involved in plugins work, so I am not the best person to answer! > > After watching the recording of Alex's KVM Forum presentation on the plugins, > he's answered my question -- he described the > rust bindings specifically as "...might require us to be a little bit more > formal about specifying a proper API..." -- so maybe > not a top priority for now.
Just to expand a little. We do have: #define QEMU_PLUGIN_VERSION 4 and #define QEMU_PLUGIN_MIN_VERSION 2 which in theory should stop you getting mixed up trying to load older plugins when the APIs change. However we have only sporadically incremented the MIN_VERSION counter so you can still run into linking issues. Adding new APIs is fairly simple but we have also deprecated or changed the API signature for existing helpers. I think once that stabilises we'll be in a better position going forward. I'm certainly very interested in Rust as plugin implementation language. Although we limit their tentacles into QEMU itself they are still very performance sensitive and in C it's easy to take shortcuts that will blow up. However the current C interface makes heavy use of GLib types and that seems something that would be clumsy to pass across a Rust API. Would be implement Rust for plugins as a wrapper around the C API or implement a purer Rust API that dealt in idiomatic rust types? Would we even consider in the long run deprecating the C API in favour or rust? > > Paolo > > This project https://github.com/novafacing/qemu-rs seems to explore this > space - maybe it would be good to incorporate something like this inside > of QEMU? <snip> -- Alex Bennée Virtualisation Tech Lead @ Linaro
