Re: [RFC PATCH v3 00/11] tcg-plugins: add hooks for discontinuities

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

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