Pierrick Bouvier <pierrick.bouv...@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. -- Alex Bennée Virtualisation Tech Lead @ Linaro
