"Julian Ganz" <ne...@skiff.uberspace.de> writes: > Hi, Pierrick, > > October 21, 2024 at 11:59 PM, "Pierrick Bouvier" wrote: >> On 10/21/24 14:02, Julian Ganz wrote: >> > The motivation for this API is a plugin that simulates a RISC-V tracing >> > unit (and produces a trace). For that we actually also needed to >> > track the "regular" control flow, i.e. find out whether a branch was >> > taken or where a jump went. That wasn't hard, especially considering >> > that the TCG API already gives you (more or less) basic blocks. Still, >> > we ended up tracing every instruction because that made some of the logic >> > much simpler and easier to reason about. >> > We realized that we need a trap API because they: >> > * can occur at any time/point of execusion >> > * usually come with additional effects such as mode changes. >> > >> Thanks for sharing your insights. >> I think there is definitely value in what you offer, and I'm trying >> to think how we could extend it in the future easily, without having >> another callback when a new event appear. In my experience on >> plugins, the least callbacks we have, and the simpler they are, the >> better it is. >> >> Maybe we could have a single API like: >> <snip> > > Traps are just too diverse, imo there is too little overlap between > different architectures, with the sole exception maybe being the PC > prior to the trap. "Interrupt id" sounds like a reasonably common > concept, but then you would need to define a mapping for each and every > architecture. What integer type do you use? In RISC-V, for example, > exceptions and interrupt "ids" are differentiated via the most > significant bit. Dou keep that or do you zero it? And then there's > ring/privilage mode, cause (sometimes for each mode), ... > > It would also complicate call sites for hooks in target code. You'd > either need awkwardly long function signitures or setup code for that > struct. Both are things you don't want, as a hook call site should > never distract from the actual logic surrounding them. You could > probably have something reasonable in Rust, using a builder/command > pattern. But in C this would require too much boiler plate code than > I'd be comfortable with.
How easy would it be to expose a Rust API? I'm curious because now we are looking to integrate Rust into QEMU we could consider transitioning to a Rust API for plugins. It has been done before: https://github.com/novafacing/qemu-rs/tree/main/qemu-plugin-sys and https://github.com/novafacing/qemu-rs/tree/main/qemu-plugin I'm curious as to what it would look like. I don't know how tenable it would be to run 2 plugin APIs side-by-side long term though. We would probably want to make a choice. Also how would that affect other C like APIs like python? > > Regards, > Julian -- Alex Bennée Virtualisation Tech Lead @ Linaro
