Re: [RFC PATCH v2 0/7] tcg-plugins: add hooks for interrupts, exceptions and traps

["Alex Bennée" <alex.bennee@linaro.org>]

"Julian Ganz" <nenut@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