Julian Ganz <neither@nut.email> writes: > Some analysis greatly benefits, or depends on, information about > certain types of dicontinuities such as 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. > > These changes introduce a generic and easy-to-use interface for plugin > authors in the form of a callback for discontinuities. Patch 1 defines > an enumeration of some trap-related discontinuities including somewhat > narrow definitions of the discontinuity evetns and a callback type. > Patch 2 defines the callback registration function. Patch 3 adds some > hooks for triggering the callbacks. Patch 4 adds an example plugin > showcasing the new API. Patches 5 through 6 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). Finally, patch 11 supplies a test plugin asserting that the > next PC provided to the plugin points to the next instruction executed. > > Sidenote: I'm likely doing something wrong for one architecture or > the other. These patches are untested for most of them.
I've finished my review pass. Overall I think the API is fine but I would like the arch maintainers to be happy the individual hooks capture the right semantics for their arches. I think Pierrick has already picked up some compile failures, you can see more from my gitlab CI run: https://gitlab.com/stsquad/qemu/-/pipelines/1618014020 As you have discovered with the discontinuity issue making sure the execution state is consistent with JIT'ed code has a few landmines in it. Given it is hard to trigger with our basic softmmu tests you should consider a few more aggressive tests like: tests/functional/test_aarch64_tcg_plugins.py where we can pick exactly which plugin we want to use and run something that will have a lot of IRQs and exceptions in it. It doesn't have to be Aarch64 - whichever arch you are most familiar with. A test that includes a hypervisor would be ideal as that will trigger a wider range of execution state changes. -- Alex Bennée Virtualisation Tech Lead @ Linaro
