| Message ID | cover.1729355735.git.neither@nut.email |
|---|---|
| Headers | show |
| Series | tcg-plugins: add hooks for interrupts, exceptions and traps | expand |
Julian Ganz <neither@nut.email> writes: > Some analysis greatly benefits, or depends on, information about > interrupts. For example, we may need to handle the execution of a new > translation block differently if it is not the result of normal program > flow but of an interrupt. For future iterations please post as a new series as tagging onto an old series will confuse tooling like patchew. I shall try and get around to reviewing later this week.
Hi Julian, On 10/19/24 09:39, Julian Ganz wrote: > Some analysis greatly benefits, or depends on, information about > interrupts. For example, we may need to handle the execution of a new > translation block differently if it is not the result of normal program > flow but of an interrupt. > > Even with the existing interfaces, it is more or less possible to > discern these situations, e.g. as done by the cflow plugin. However, > this process poses a considerable overhead to the core analysis one may > intend to perform. > I agree it would be useful. Beyond the scope of this series, it would be nice if we could add a control flow related API instead of asking to plugins to do it themselves. If we would provide something like this, is there still a value to add an API to detect interrupt/exceptions/traps events? Note: It's not a critic against what you sent, just an open question on *why* it's useful to access this QEMU implementation related information vs something more generic. > These changes introduce a generic and easy-to-use interface for plugin > authors in the form of callbacks for different types of traps. Patch 1 > defines the callback registration functions and supplies a somewhat > narrow definition of the event the callbacks are called. Patch 2 adds > some hooks for triggering the callbacks. Patch 3 adds an example plugin > showcasing the new API. The remaining patches call the hooks for a > selection of architectures, mapping architecture specific events to the > three categories defined in patch 1. Future non-RFC patchsets will call > these hooks for all architectures (that have some concept of trap or > interrupt). > > Sidenote: I'm likely doing something wrong for one architecture or > the other. For example, with the old version Alex Bennée suggested > registering a helper function with arm_register_el_change_hook() for > arm, which is not what I ended up doing. And for AVR my approach to just > assume only (asynchroneous) interrupts exist is also likely too naïve. > > Since v1: > - Split the one callback into multiple callbacks > - Added a target-agnostic definition of the relevant event(s) > - Call hooks from architecture-code rather than accel/tcg/cpu-exec.c > - Added a plugin showcasing API usage > > Julian Ganz (7): > plugins: add API for registering trap related callbacks > plugins: add hooks for new trap related callbacks > contrib/plugins: add plugin showcasing new trap related API > target/arm: call plugin trap callbacks > target/avr: call plugin trap callbacks > target/riscv: call plugin trap callbacks > target/sparc: call plugin trap callbacks > > contrib/plugins/Makefile | 1 + > contrib/plugins/traps.c | 89 ++++++++++++++++++++++++++++++++++++ > include/qemu/plugin-event.h | 3 ++ > include/qemu/plugin.h | 12 +++++ > include/qemu/qemu-plugin.h | 45 ++++++++++++++++++ > plugins/core.c | 42 +++++++++++++++++ > plugins/qemu-plugins.symbols | 3 ++ > target/arm/helper.c | 23 ++++++++++ > target/avr/helper.c | 3 ++ > target/riscv/cpu_helper.c | 8 ++++ > target/sparc/int32_helper.c | 7 +++ > target/sparc/int64_helper.c | 10 ++++ > 12 files changed, 246 insertions(+) > create mode 100644 contrib/plugins/traps.c >
Pierrick Bouvier <pierrick.bouvier@linaro.org> writes: > Hi Julian, > > On 10/19/24 09:39, Julian Ganz wrote: >> Some analysis greatly benefits, or depends on, information about >> interrupts. For example, we may need to handle the execution of a new >> translation block differently if it is not the result of normal program >> flow but of an interrupt. >> Even with the existing interfaces, it is more or less possible to >> discern these situations, e.g. as done by the cflow plugin. However, >> this process poses a considerable overhead to the core analysis one may >> intend to perform. >> > > I agree it would be useful. Beyond the scope of this series, it would > be nice if we could add a control flow related API instead of asking > to plugins to do it themselves. I think there is a balance to be had here. We don't want to inadvertently expose QEMU internals to the plugin API. With this series at least we rely on stuff the front-end knows which can at least be tweaked relatively easily. > If we would provide something like this, is there still a value to add > an API to detect interrupt/exceptions/traps events? > > Note: It's not a critic against what you sent, just an open question > on *why* it's useful to access this QEMU implementation related > information vs something more generic. <snip> It would be good to have the opinion of the front-end maintainers if this is too burdensome or easy enough to manage.
On 10/21/24 11:47, Alex Bennée wrote: > Pierrick Bouvier <pierrick.bouvier@linaro.org> writes: > >> Hi Julian, >> >> On 10/19/24 09:39, Julian Ganz wrote: >>> Some analysis greatly benefits, or depends on, information about >>> interrupts. For example, we may need to handle the execution of a new >>> translation block differently if it is not the result of normal program >>> flow but of an interrupt. >>> Even with the existing interfaces, it is more or less possible to >>> discern these situations, e.g. as done by the cflow plugin. However, >>> this process poses a considerable overhead to the core analysis one may >>> intend to perform. >>> >> >> I agree it would be useful. Beyond the scope of this series, it would >> be nice if we could add a control flow related API instead of asking >> to plugins to do it themselves. > > I think there is a balance to be had here. We don't want to > inadvertently expose QEMU internals to the plugin API. With this series > at least we rely on stuff the front-end knows which can at least be > tweaked relatively easily. > You're right. Maybe a good way to find the balance is to identify the real use cases behind this need. >> If we would provide something like this, is there still a value to add >> an API to detect interrupt/exceptions/traps events? >> >> Note: It's not a critic against what you sent, just an open question >> on *why* it's useful to access this QEMU implementation related >> information vs something more generic. > <snip> > > It would be good to have the opinion of the front-end maintainers if > this is too burdensome or easy enough to manage. > >
Hi, Pierrick, October 21, 2024 at 8:00 PM, "Pierrick Bouvier" wrote: > I agree it would be useful. Beyond the scope of this series, it would be > nice if we could add a control flow related API instead of asking to > plugins to do it themselves. > > If we would provide something like this, is there still a value to add > an API to detect interrupt/exceptions/traps events? > > Note: It's not a critic against what you sent, just an open question on > *why* it's useful to access this QEMU implementation related information > vs something more generic. 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. Helpers for discerning whether an instruction is a jump, a branch instruction or something else would certainly be helpful if you wanted cross-platform control flow tracing of some sort, but afaik given such helpers you would just need to check the last instruction in a translation block and check where the PC goes after that. Additional callbacks for specifically this situation strike me as a bit excessive. But I could be wrong about that. Regards, Julian
On 10/21/24 14:02, Julian Ganz wrote: > Hi, Pierrick, > > October 21, 2024 at 8:00 PM, "Pierrick Bouvier" wrote: >> I agree it would be useful. Beyond the scope of this series, it would be >> nice if we could add a control flow related API instead of asking to >> plugins to do it themselves. >> >> If we would provide something like this, is there still a value to add >> an API to detect interrupt/exceptions/traps events? >> >> Note: It's not a critic against what you sent, just an open question on >> *why* it's useful to access this QEMU implementation related information >> vs something more generic. > > 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: enum qemu_plugin_cf_event_type { QEMU_PLUGIN_CF_INTERRUPT; QEMU_PLUGIN_CF_TRAP; QEMU_PLUGIN_CF_SEMIHOSTING; }; /* Sum type, a.k.a. "Rust-like" enum */ typedef struct { enum qemu_plugin_cf_event_type ev; union { data_for_interrupt interrupt; data_for_trap trap; data_for_semihosting semihosting; } qemu_plugin_cf_event; /* data_for_... could contain things like from/to addresses, interrupt id, ... */ ... void on_cf_event(qemu_plugin_cf_event ev) { switch (ev.type) { case QEMU_PLUGIN_CF_TRAP: ... case QEMU_PLUGIN_CF_SEMIHOSTING: ... default: g_assert_not_reached(); } } /* a plugin can register to one or several event - we could provide a QEMU_PLUGIN_CF_ALL for plugins tracking all events. */ qemu_plugin_register_cf_cb(QEMU_PLUGIN_CF_TRAP, &on_cf_event); qemu_plugin_register_cf_cb(QEMU_PLUGIN_CF_SEMIHOSTING, &on_cf_event); This way, a single callback can be registered for one or several events. And in the future, we are free to attach more data for every event, and add other events (TB_FALLTHROUGH, TB_JUMP, etc). > Helpers for discerning whether an instruction is a jump, a branch > instruction or something else would certainly be helpful if you wanted > cross-platform control flow tracing of some sort, but afaik given such > helpers you would just need to check the last instruction in a > translation block and check where the PC goes after that. Additional > callbacks for specifically this situation strike me as a bit > excessive. > > But I could be wrong about that. > You're right, and the current cflow plugin is more a demonstration of using existing API than an efficient solution to this problem. For cflow detection specifically, I think we can do better, by adding instrumentation right where we chain/jump between tb, and of course, tracking other events like you did in this series. > Regards, > Julian
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: > > enum qemu_plugin_cf_event_type { > QEMU_PLUGIN_CF_INTERRUPT; > QEMU_PLUGIN_CF_TRAP; > QEMU_PLUGIN_CF_SEMIHOSTING; > }; I have considered such an enum, as an input for the callback, as a parameter of the registration function, and both. Of course, if you were to add a selection parameter for the registration function, you likely want OR-able flags. An additional input for the callback type would obviously require a new function type just for that callback. Since the callbacks are somewhat similar to the VCPU init, exit, resume, ... ones it felt appropriate to use the same function type for all of them. As for the registration, it may make the registration a bit more convenient and maybe keep the API clutter a bit lower, but not by that much. > /* Sum type, a.k.a. "Rust-like" enum */ > typedef struct { > enum qemu_plugin_cf_event_type ev; > union { > data_for_interrupt interrupt; > data_for_trap trap; > data_for_semihosting semihosting; > } qemu_plugin_cf_event; > /* data_for_... could contain things like from/to addresses, interrupt id, ... */ I don't think this is a good idea. 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. Regards, Julian
"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
Hi, Alex, October 22, 2024 at 10:58 AM, "Alex Bennée" wrote: > 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? I'm maybe not an expert w.r.t. plugins with Rust, but here are my thoughts: Calling C code from Rust is obviously not an issue. For ideomatic Rust (not littered with "unsafe") you want an abstraction over that, but as Qemu is C you need that somewhere anyway. Things that are generally easy to handle are opaque types behind pointers (this is probably true for most language binding) and C strings, as long as you can figure out who owns them and how long they live. Things in the current API which make things a bit awkward are (probably) unions and Glib-types such as the GArray returned by qemu_plugin_get_registers. Also, you can use Rust functions for callbacks, but ideally you want to allow using all types implementing the Fn trait, e.g. closures carrying some context. For that, you need to transport that context from the point of registration to the callback, i.e. you need some udata. Not all callbacks have udata, but looking closer the ones lacking it are those you register only once, which means we could have some "static" storage for those context. It's not ideal, but not a show-stopper either. I didn't check how the qemu-plugin crate handles that situation. With a native Rust interface, you would not have those problems. However, for plugins you would need a dylib interface, which comes with restrictions. In particular, you cannot use generics in the interface. To allow for the very extension we want the interface would make heavy use of Box<dyn SomeTrait>, in particular Box<dyn Fn(...) -> ...>. The awkward thing about those is that you cannot simply convert them into a void pointer because the "dyn" means fat pointers are involved: unlike in C++, the vtable is embedded in the "pointer". Since we want to invoke those from the C side, we need another level of indirection which lets us operate on an opaque Rust type through non-generic functions that then does the thing we want to the boxed thing. Ironically, you don't have the same problem with a Rust plugin developed against a C interface because you can just use a generic function unpacking (i.e. casting) the context and throw its instantiation's pointer over the fence. So... I'm not sure about the benefits of a native Rust plugin API compared to the qemu-plugin crate or something similar. Especially considering that we would want to use the very same callback registry in the back, anyway. That is, if you want feature parity between the different plugin APIs. There are some things that would make language bindings easier in general, but some of those would involve breaking changes and may not be worth it. Regards, Julian
On 10/22/24 01:21, Julian Ganz wrote: > 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: >> >> enum qemu_plugin_cf_event_type { >> QEMU_PLUGIN_CF_INTERRUPT; >> QEMU_PLUGIN_CF_TRAP; >> QEMU_PLUGIN_CF_SEMIHOSTING; >> }; > > I have considered such an enum, as an input for the callback, as a > parameter of the registration function, and both. Of course, if you were > to add a selection parameter for the registration function, you likely > want OR-able flags. > > An additional input for the callback type would obviously require a new > function type just for that callback. Since the callbacks are somewhat > similar to the VCPU init, exit, resume, ... ones it felt appropriate > to use the same function type for all of them. > I tend to disagree on that. IMHO, it's better to reduce number of API entries instead of callback types. It's easy for a user to understand how to implement a given callback, while it's hard to understand which API you need for which thing. For the syscall cbs, we already have a specific callback. So why not here? I tend to see init/exit/resume events as different because you can't get useful information attached, except the cpu id. But for control flow related stuff, you can be interested in having more. I understand you're focused on those "events" for now, but while digging into this, it seems like the initial need was to track the control flow. So I would like to push more in this direction, and offer a more extendable solution. Do you think the end goal for a plugin using this information may be different? (beyond a plugin counting trap/interrupts/semihosting event). > As for the registration, it may make the registration a bit more > convenient and maybe keep the API clutter a bit lower, but not by that > much. > It's ok for the user. But I think it's more complicated to extend, when we'll want to introduce control flow API in the future. Do we want 5 or 6 different callbacks when people want to track fully control flow from a plugin? > >> /* Sum type, a.k.a. "Rust-like" enum */ >> typedef struct { >> enum qemu_plugin_cf_event_type ev; >> union { >> data_for_interrupt interrupt; >> data_for_trap trap; >> data_for_semihosting semihosting; >> } qemu_plugin_cf_event; >> /* data_for_... could contain things like from/to addresses, interrupt id, ... */ > > I don't think this is a good idea. > > 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), ... > I didn't want to open the per architecture pandora box :). I don't think the plugin API itself should deal with per architecture details like meaning of a given id. I was just thinking to push this "raw" information to the plugin, that may/may not use architecture specific knowledge to do its work. We already have plugins that have similar per architecture knowledge (contrib/plugins/howvec.c) and it's ok in some specific cases. But having something like from/to address seems useful to start. Even if we don't provide it for all events yet, it's ok. > 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. > We can have one "builder" function per data type, with fixed parameters (no varargs), it's reasonable and would scale well with new entries/data information. > Regards, > Julian
Hi, Pierrick, resent as I was too stupid to hit reply instead of reply-all. October 22, 2024 at 11:15 PM, "Pierrick Bouvier" wrote: > > On 10/22/24 01:21, Julian Ganz wrote: > > > > > Hi, Pierrick, > > October 21, 2024 at 11:59 PM, "Pierrick Bouvier" wrote: > > > > > > > > Maybe we could have a single API like: > > > > > > enum qemu_plugin_cf_event_type { > > > QEMU_PLUGIN_CF_INTERRUPT; > > > QEMU_PLUGIN_CF_TRAP; > > > QEMU_PLUGIN_CF_SEMIHOSTING; > > > }; > > > > > I have considered such an enum, as an input for the callback, as a > > parameter of the registration function, and both. Of course, if you were > > to add a selection parameter for the registration function, you likely > > want OR-able flags. > > An additional input for the callback type would obviously require a new > > function type just for that callback. Since the callbacks are somewhat > > similar to the VCPU init, exit, resume, ... ones it felt appropriate > > to use the same function type for all of them. > > > I tend to disagree on that. IMHO, it's better to reduce number of API entries instead of callback types. > It's easy for a user to understand how to implement a given callback, while it's hard to understand which API you need for which thing. > > For the syscall cbs, we already have a specific callback. So why not here? <snip> > > As for the registration, it may make the registration a bit more > > convenient and maybe keep the API clutter a bit lower, but not by that > > much. > > > It's ok for the user. But I think it's more complicated to extend, when we'll want to introduce control flow API in the future. Do we want 5 or 6 different callbacks when people want to track fully control flow from a plugin? Ok, I'll introduce an enum and combine the three callbacks in the next iteration then. > > > typedef struct { > > > enum qemu_plugin_cf_event_type ev; > > > union { > > > data_for_interrupt interrupt; > > > data_for_trap trap; > > > data_for_semihosting semihosting; > > > } qemu_plugin_cf_event; > > > /* data_for_... could contain things like from/to addresses, interrupt id, ... */ > > > > > I don't think this is a good idea. > > 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), ... > > > I didn't want to open the per architecture pandora box :). > I don't think the plugin API itself should deal with per architecture > details like meaning of a given id. I was just thinking to push this "raw" information to the plugin, that may/may not use architecture specific knowledge to do its work. We already have plugins that have similar per architecture knowledge (contrib/plugins/howvec.c) and it's ok in some specific cases. But how would such an interface look? The last PC aside, what would you include, and how? A GArray with named items that are itself just opaque blobs? And what would be the benefit compared to just querying the respective target specific registers through qemu_plugin_read_register? Which btw. is what we were going to do for our use-case. Even the example you brought up (howvec) uses querying functions and doesn't expect to get all the info via parameters. > But having something like from/to address seems useful to start. Even if we don't provide it for all events yet, it's ok. Yes, I certainly see the advantages of having either the last PC or the would-be-next PC as they are sufficiently universal. You can usually retrieve them from target-specific registers, but that may be more complicated in practice. In the case of RISC-V for example, the value of the EPC differs between interrupts and exceptions. That PC value should also be easy enough to obtain at the hook call sites. We only need to store the (old) PC before doing the setup. The "to-address" is the current PC at the time the callback is invoked. Anything else would be a bug. I was going to write that you can already query that in a plugin through a dedicated helper function but apparently I misremembered. I'll include this in the next iteration. > > 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. > > > We can have one "builder" function per data type, with fixed parameters (no varargs), it's reasonable and would scale well with new entries/data information. I'm still not on board on preparing a more complex data type. For the next iteration I'd rather stick to a simple function receiving the "type" of event and the PCs. That may not be extensible, but I don't see any benefit in shoehorning inheritelntly target-specifc information into a complex struct. If this is a hard requirement, I'll of course still do so. Regards, Julian
"Julian Ganz" <nenut@skiff.uberspace.de> writes: > Hi, Pierrick, > > resent as I was too stupid to hit reply instead of reply-all. > > October 22, 2024 at 11:15 PM, "Pierrick Bouvier" wrote: >> >> On 10/22/24 01:21, Julian Ganz wrote: >> >> > >> > Hi, Pierrick, >> > October 21, 2024 at 11:59 PM, "Pierrick Bouvier" wrote: >> > <snip> >> > I don't think this is a good idea. >> > 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), ... >> > >> I didn't want to open the per architecture pandora box :). >> I don't think the plugin API itself should deal with per architecture >> details like meaning of a given id. I was just thinking to push this >> "raw" information to the plugin, that may/may not use architecture >> specific knowledge to do its work. We already have plugins that have >> similar per architecture knowledge (contrib/plugins/howvec.c) and >> it's ok in some specific cases. > > But how would such an interface look? The last PC aside, what would you > include, and how? A GArray with named items that are itself just opaque > blobs? > > And what would be the benefit compared to just querying the respective > target specific registers through qemu_plugin_read_register? Which btw. > is what we were going to do for our use-case. Even the example you > brought up (howvec) uses querying functions and doesn't expect to get > all the info via parameters. I think the register access probably provides everything you need. Some targets provide a wider access than other though. I haven't looked at the Risc V code but certainly the Arm code exposes pretty much all system registers to the gdbstub (and hence the plugin interface). If there is example of state that isn't accessible this way then I'd like to know it. >> But having something like from/to address seems useful to start. Even if we don't provide it for all events yet, it's ok. > > Yes, I certainly see the advantages of having either the last PC or the > would-be-next PC as they are sufficiently universal. You can usually > retrieve them from target-specific registers, but that may be more > complicated in practice. In the case of RISC-V for example, the value > of the EPC differs between interrupts and exceptions. > > That PC value should also be easy enough to obtain at the hook call > sites. We only need to store the (old) PC before doing the setup. The > "to-address" is the current PC at the time the callback is invoked. > Anything else would be a bug. I was going to write that you can > already query that in a plugin through a dedicated helper function > but apparently I misremembered. > > I'll include this in the next iteration. There are some dragons with pc/npc as each front-end deals with it its own way and some targets have delay slots which makes things even messier. > >> > 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. >> > >> We can have one "builder" function per data type, with fixed parameters (no varargs), it's reasonable and would scale well with new entries/data information. > > I'm still not on board on preparing a more complex data type. For the > next iteration I'd rather stick to a simple function receiving the > "type" of event and the PCs. That may not be extensible, but I don't see > any benefit in shoehorning inheritelntly target-specifc information into > a complex struct. > > If this is a hard requirement, I'll of course still do so. No lets keep it simple for the first iteration. We can also expand the API later and bump the API versions as appropriate. > > Regards, > Julian
Hi Julian, On 10/23/24 05:56, Julian Ganz wrote: > Hi, Pierrick, > > resent as I was too stupid to hit reply instead of reply-all. > > October 22, 2024 at 11:15 PM, "Pierrick Bouvier" wrote: >> >> On 10/22/24 01:21, Julian Ganz wrote: >> >>> >>> Hi, Pierrick, >>> October 21, 2024 at 11:59 PM, "Pierrick Bouvier" wrote: >>> >>>> >>>> Maybe we could have a single API like: >>>> >>>> enum qemu_plugin_cf_event_type { >>>> QEMU_PLUGIN_CF_INTERRUPT; >>>> QEMU_PLUGIN_CF_TRAP; >>>> QEMU_PLUGIN_CF_SEMIHOSTING; >>>> }; >>>> >>> I have considered such an enum, as an input for the callback, as a >>> parameter of the registration function, and both. Of course, if you were >>> to add a selection parameter for the registration function, you likely >>> want OR-able flags. >>> An additional input for the callback type would obviously require a new >>> function type just for that callback. Since the callbacks are somewhat >>> similar to the VCPU init, exit, resume, ... ones it felt appropriate >>> to use the same function type for all of them. >>> >> I tend to disagree on that. IMHO, it's better to reduce number of API entries instead of callback types. >> It's easy for a user to understand how to implement a given callback, while it's hard to understand which API you need for which thing. >> >> For the syscall cbs, we already have a specific callback. So why not here? > > <snip> > >>> As for the registration, it may make the registration a bit more >>> convenient and maybe keep the API clutter a bit lower, but not by that >>> much. >>> >> It's ok for the user. But I think it's more complicated to extend, when we'll want to introduce control flow API in the future. Do we want 5 or 6 different callbacks when people want to track fully control flow from a plugin? > > Ok, I'll introduce an enum and combine the three callbacks in the next > iteration then. > >>>> typedef struct { >>>> enum qemu_plugin_cf_event_type ev; >>>> union { >>>> data_for_interrupt interrupt; >>>> data_for_trap trap; >>>> data_for_semihosting semihosting; >>>> } qemu_plugin_cf_event; >>>> /* data_for_... could contain things like from/to addresses, interrupt id, ... */ >>>> >>> I don't think this is a good idea. >>> 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), ... >>> >> I didn't want to open the per architecture pandora box :). >> I don't think the plugin API itself should deal with per architecture >> details like meaning of a given id. I was just thinking to push this "raw" information to the plugin, that may/may not use architecture specific knowledge to do its work. We already have plugins that have similar per architecture knowledge (contrib/plugins/howvec.c) and it's ok in some specific cases. > > But how would such an interface look? The last PC aside, what would you > include, and how? A GArray with named items that are itself just opaque > blobs? > I was not thinking about a new interface for this. Having the "raw" interrupt id is enough for a plugin to do useful things, by having knowledge of which architecture it's instrumenting. > And what would be the benefit compared to just querying the respective > target specific registers through qemu_plugin_read_register? Which btw. > is what we were going to do for our use-case. Even the example you > brought up (howvec) uses querying functions and doesn't expect to get > all the info via parameters. > You're right, but it's because it's querying instruction data. I may be wrong on that, but at translation time, we may or may not be interested in accessing tb/insn data. However, for control flow analysis, beyond a simple counting plugin, we probably want to access further data almost everytime. I see it closer from syscall instrumentation, which pushes the syscall id, and all register values, instead of letting the user poke it. Makes more sense compared to that? >> But having something like from/to address seems useful to start. Even if we don't provide it for all events yet, it's ok. > > Yes, I certainly see the advantages of having either the last PC or the > would-be-next PC as they are sufficiently universal. You can usually > retrieve them from target-specific registers, but that may be more > complicated in practice. In the case of RISC-V for example, the value > of the EPC differs between interrupts and exceptions. > To the opposite of interrupt id, a PC is something universal by definition, and with a single meaning across architecture. However, accessing it by name varies per architecture, and even per sub events, as you are stating for RISC-V. > That PC value should also be easy enough to obtain at the hook call > sites. We only need to store the (old) PC before doing the setup. The > "to-address" is the current PC at the time the callback is invoked. > Anything else would be a bug. I was going to write that you can > already query that in a plugin through a dedicated helper function > but apparently I misremembered. > > I'll include this in the next iteration. > >>> 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. >>> >> We can have one "builder" function per data type, with fixed parameters (no varargs), it's reasonable and would scale well with new entries/data information. > > I'm still not on board on preparing a more complex data type. For the > next iteration I'd rather stick to a simple function receiving the > "type" of event and the PCs. That may not be extensible, but I don't see > any benefit in shoehorning inheritelntly target-specifc information into > a complex struct. > It's a good compromise for now, and avoid introducing a more complex data type. > If this is a hard requirement, I'll of course still do so. > My goal was not to hijack this series, or put the burden on you, but to talk about which direction we want to go. As long as we start with a single callback (vs one per event), I'm fine to go slowly and iterate in the future. > Regards, > Julian Thanks Julian!
On 10/23/24 06:57, Alex Bennée wrote: > "Julian Ganz" <nenut@skiff.uberspace.de> writes: > >> Hi, Pierrick, >> >> resent as I was too stupid to hit reply instead of reply-all. >> >> October 22, 2024 at 11:15 PM, "Pierrick Bouvier" wrote: >>> >>> On 10/22/24 01:21, Julian Ganz wrote: >>> >>>> >>>> Hi, Pierrick, >>>> October 21, 2024 at 11:59 PM, "Pierrick Bouvier" wrote: >>>> > <snip> >>>> I don't think this is a good idea. >>>> 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), ... >>>> >>> I didn't want to open the per architecture pandora box :). >>> I don't think the plugin API itself should deal with per architecture >>> details like meaning of a given id. I was just thinking to push this >>> "raw" information to the plugin, that may/may not use architecture >>> specific knowledge to do its work. We already have plugins that have >>> similar per architecture knowledge (contrib/plugins/howvec.c) and >>> it's ok in some specific cases. >> >> But how would such an interface look? The last PC aside, what would you >> include, and how? A GArray with named items that are itself just opaque >> blobs? >> >> And what would be the benefit compared to just querying the respective >> target specific registers through qemu_plugin_read_register? Which btw. >> is what we were going to do for our use-case. Even the example you >> brought up (howvec) uses querying functions and doesn't expect to get >> all the info via parameters. > > I think the register access probably provides everything you need. Some > targets provide a wider access than other though. I haven't looked at > the Risc V code but certainly the Arm code exposes pretty much all > system registers to the gdbstub (and hence the plugin interface). > > If there is example of state that isn't accessible this way then I'd > like to know it. > >>> But having something like from/to address seems useful to start. Even if we don't provide it for all events yet, it's ok. >> >> Yes, I certainly see the advantages of having either the last PC or the >> would-be-next PC as they are sufficiently universal. You can usually >> retrieve them from target-specific registers, but that may be more >> complicated in practice. In the case of RISC-V for example, the value >> of the EPC differs between interrupts and exceptions. >> >> That PC value should also be easy enough to obtain at the hook call >> sites. We only need to store the (old) PC before doing the setup. The >> "to-address" is the current PC at the time the callback is invoked. >> Anything else would be a bug. I was going to write that you can >> already query that in a plugin through a dedicated helper function >> but apparently I misremembered. >> >> I'll include this in the next iteration. > > There are some dragons with pc/npc as each front-end deals with it its > own way and some targets have delay slots which makes things even > messier. > Yes, if it gets too complicated for current series, we can just have the event passed to the callback, and no more information. As pointed in my previous message, I just want to avoid the multiple callbacks route for this specific area. It's fine if we don't have any attached data for now. >> >>>> 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. >>>> >>> We can have one "builder" function per data type, with fixed parameters (no varargs), it's reasonable and would scale well with new entries/data information. >> >> I'm still not on board on preparing a more complex data type. For the >> next iteration I'd rather stick to a simple function receiving the >> "type" of event and the PCs. That may not be extensible, but I don't see >> any benefit in shoehorning inheritelntly target-specifc information into >> a complex struct. >> >> If this is a hard requirement, I'll of course still do so. > > No lets keep it simple for the first iteration. We can also expand the > API later and bump the API versions as appropriate. > The type of event, eventually with pcs if you can get them is already satisfying, and simple enough. >> >> Regards, >> Julian >
Hi, Pierrick, October 23, 2024 at 5:16 PM, "Pierrick Bouvier" wrote: > > Hi Julian, > > On 10/23/24 05:56, Julian Ganz wrote: > > > October 22, 2024 at 11:15 PM, "Pierrick Bouvier" wrote: > > > > > > > > On 10/22/24 01:21, Julian Ganz wrote: > > > > > > > Ok, I'll introduce an enum and combine the three callbacks in the next > > iteration then. > > typedef struct { > > enum qemu_plugin_cf_event_type ev; > > union { > > data_for_interrupt interrupt; > > data_for_trap trap; > > data_for_semihosting semihosting; > > } qemu_plugin_cf_event; > > /* data_for_... could contain things like from/to addresses, interrupt id, ... */ > > > > I don't think this is a good idea. > > 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), ... > > > > > > > > I didn't want to open the per architecture pandora box :). > > > I don't think the plugin API itself should deal with per architecture > > > details like meaning of a given id. I was just thinking to push this "raw" information to the plugin, that may/may not use architecture specific knowledge to do its work. We already have plugins that have similar per architecture knowledge (contrib/plugins/howvec.c) and it's ok in some specific cases. > > > > > But how would such an interface look? The last PC aside, what would you > > include, and how? A GArray with named items that are itself just opaque > > blobs? > > > I was not thinking about a new interface for this. Having the "raw" interrupt id is enough for a plugin to do useful things, by having knowledge of which architecture it's instrumenting. But what is would the "raw" interrupt id even be for a given architecture? I don't think you can answer this question with "obviously this _one_ integer" for all of them. > > > > And what would be the benefit compared to just querying the respective > > target specific registers through qemu_plugin_read_register? Which btw. > > is what we were going to do for our use-case. Even the example you > > brought up (howvec) uses querying functions and doesn't expect to get > > all the info via parameters. > > > You're right, but it's because it's querying instruction data. > I may be wrong on that, but at translation time, we may or may not be interested in accessing tb/insn data. > > However, for control flow analysis, beyond a simple counting plugin, we probably want to access further data almost everytime. > > I see it closer from syscall instrumentation, which pushes the syscall id, and all register values, instead of letting the user poke it. Makes more sense compared to that? Yes, but then you are in "GArray of named, potentially complex value" terretory again. And the comparison with syscalls also falls apart when you consider that, for syscalls, they are well defined and enumerated identically for at least a variety of targets, while the same kind of "enumeration", if it even exists, is in completely different order for every architecture. > > > > > > > > But having something like from/to address seems useful to start. Even if we don't provide it for all events yet, it's ok. > > > > > Yes, I certainly see the advantages of having either the last PC or the > > would-be-next PC as they are sufficiently universal. You can usually > > retrieve them from target-specific registers, but that may be more > > complicated in practice. In the case of RISC-V for example, the value > > of the EPC differs between interrupts and exceptions. > > > To the opposite of interrupt id, a PC is something universal by definition, and with a single meaning across architecture. However, accessing it by name varies per architecture, and even per sub events, as you are stating for RISC-V. Yes. And for that very reason I would not pass "the EPC" to a callback but a clearly, target agnostic, defined value such as: | The PC of the instruction that would have been executed next, were it | not for that event or | The PC of the instruction that was executed befroe the event occurred And unlike interrupt ids, the plugin API already has a precedent for what type to use: uint64_t Regards, Julian
On 10/23/24 09:12, Julian Ganz wrote: > Hi, Pierrick, > > October 23, 2024 at 5:16 PM, "Pierrick Bouvier" wrote: >> >> Hi Julian, >> >> On 10/23/24 05:56, Julian Ganz wrote: >> >>> October 22, 2024 at 11:15 PM, "Pierrick Bouvier" wrote: >>> >>>> >>>> On 10/22/24 01:21, Julian Ganz wrote: >>>> >>> >>> Ok, I'll introduce an enum and combine the three callbacks in the next >>> iteration then. >>> typedef struct { >>> enum qemu_plugin_cf_event_type ev; >>> union { >>> data_for_interrupt interrupt; >>> data_for_trap trap; >>> data_for_semihosting semihosting; >>> } qemu_plugin_cf_event; >>> /* data_for_... could contain things like from/to addresses, interrupt id, ... */ >>> >>> I don't think this is a good idea. >>> 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), ... >>> >>>> >>>> I didn't want to open the per architecture pandora box :). >>>> I don't think the plugin API itself should deal with per architecture >>>> details like meaning of a given id. I was just thinking to push this "raw" information to the plugin, that may/may not use architecture specific knowledge to do its work. We already have plugins that have similar per architecture knowledge (contrib/plugins/howvec.c) and it's ok in some specific cases. >>>> >>> But how would such an interface look? The last PC aside, what would you >>> include, and how? A GArray with named items that are itself just opaque >>> blobs? >>> >> I was not thinking about a new interface for this. Having the "raw" interrupt id is enough for a plugin to do useful things, by having knowledge of which architecture it's instrumenting. > > But what is would the "raw" interrupt id even be for a given > architecture? I don't think you can answer this question with "obviously > this _one_ integer" for all of them. > Choosing interrupt id as an example of what we want to include was confusing, and brought more conversation than I expected. I wanted to point that we may want different data per event, instead of talking specifically of interrupt or per architecture specific data. To still answer you, I was thinking sharing interrupt number for x86_64, or interrupt id for aarch64. It's probably too naive, so let's drop this and move on :). >>> >>> And what would be the benefit compared to just querying the respective >>> target specific registers through qemu_plugin_read_register? Which btw. >>> is what we were going to do for our use-case. Even the example you >>> brought up (howvec) uses querying functions and doesn't expect to get >>> all the info via parameters. >>> >> You're right, but it's because it's querying instruction data. >> I may be wrong on that, but at translation time, we may or may not be interested in accessing tb/insn data. >> >> However, for control flow analysis, beyond a simple counting plugin, we probably want to access further data almost everytime. >> >> I see it closer from syscall instrumentation, which pushes the syscall id, and all register values, instead of letting the user poke it. Makes more sense compared to that? > > Yes, but then you are in "GArray of named, potentially complex value" > terretory again. And the comparison with syscalls also falls apart when > you consider that, for syscalls, they are well defined and enumerated > identically for at least a variety of targets, while the same kind of > "enumeration", if it even exists, is in completely different order for > every architecture. > We can restrict to having from/to PCs for now. Mentioning interrupt id as example was a mistake. >>> >>>> >>>> But having something like from/to address seems useful to start. Even if we don't provide it for all events yet, it's ok. >>>> >>> Yes, I certainly see the advantages of having either the last PC or the >>> would-be-next PC as they are sufficiently universal. You can usually >>> retrieve them from target-specific registers, but that may be more >>> complicated in practice. In the case of RISC-V for example, the value >>> of the EPC differs between interrupts and exceptions. >>> >> To the opposite of interrupt id, a PC is something universal by definition, and with a single meaning across architecture. However, accessing it by name varies per architecture, and even per sub events, as you are stating for RISC-V. > > Yes. And for that very reason I would not pass "the EPC" to a callback > but a clearly, target agnostic, defined value such as: > > | The PC of the instruction that would have been executed next, were it > | not for that event > > or > > | The PC of the instruction that was executed befroe the event occurred > > And unlike interrupt ids, the plugin API already has a precedent for > what type to use: uint64_t > Looks good. As said in previous message, we can drop the complex data type idea. So we could have something like: /* plugin side */ void on_cf_event(qemu_plugin_cf_event_type, uint64_t from, uint64_t to) { ... } /* API side */ void qemu_plugin_register_vcpu_syscall_cb( qemu_plugin_id_t id, qemu_plugin_cf_event_type type, qemu_plugin_register_vcpu_cf_cb); We thus would have a new callback type qemu_plugin_vcpu_cf_cb_t added. For registering several events, we might define enum values for types indexed on every bit, so we can directly xor the enum to register several types. (same idea than existing qemu_plugin_mem_rw, but for more values, with a specific ALL value covering all possibilities). Does that match what you were thinking? > Regards, > Julian
Hi, Pierrick, October 23, 2024 at 6:39 PM, "Pierrick Bouvier" wrote: > > So we could have something like: > > /* plugin side */ > void on_cf_event(qemu_plugin_cf_event_type, uint64_t from, uint64_t to) { > ... > } We also need the VCPU id, but yes. > /* API side */ > void qemu_plugin_register_vcpu_syscall_cb( > qemu_plugin_id_t id, qemu_plugin_cf_event_type type, qemu_plugin_register_vcpu_cf_cb); > > We thus would have a new callback type qemu_plugin_vcpu_cf_cb_t added. > > For registering several events, we might define enum values for types indexed on every bit, so we can directly xor the enum to register several types. (same idea than existing qemu_plugin_mem_rw, but for more values, with a specific ALL value covering all possibilities). > > Does that match what you were thinking? Yes. Regards, Julian
On 10/23/24 10:12, Julian Ganz wrote: > Hi, Pierrick, > > October 23, 2024 at 6:39 PM, "Pierrick Bouvier" wrote: >> >> So we could have something like: >> >> /* plugin side */ >> void on_cf_event(qemu_plugin_cf_event_type, uint64_t from, uint64_t to) { >> ... >> } > > We also need the VCPU id, but yes. Yes! > >> /* API side */ >> void qemu_plugin_register_vcpu_syscall_cb( >> qemu_plugin_id_t id, qemu_plugin_cf_event_type type, qemu_plugin_register_vcpu_cf_cb); >> >> We thus would have a new callback type qemu_plugin_vcpu_cf_cb_t added. >> >> For registering several events, we might define enum values for types indexed on every bit, so we can directly xor the enum to register several types. (same idea than existing qemu_plugin_mem_rw, but for more values, with a specific ALL value covering all possibilities). >> >> Does that match what you were thinking? > > Yes. > > Regards, > Julian