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
