While we attempt to hide implementation details from the plugin we
shouldn't be totally obtuse. Let the user know what they can and can't
expect with the various instrumentation options.

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
---
 docs/devel/tcg-plugins.rst | 49 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 49 insertions(+)

diff --git a/docs/devel/tcg-plugins.rst b/docs/devel/tcg-plugins.rst
index 535a74684c5..9cc09d8c3da 100644
--- a/docs/devel/tcg-plugins.rst
+++ b/docs/devel/tcg-plugins.rst
@@ -112,6 +112,55 @@ details are opaque to plugins. The plugin is able to query select
 details of instructions and system configuration only through the
 exported *qemu_plugin* functions.
 
+However the following assumptions can be made:
+
+Translation Blocks
+++++++++++++++++++
+
+All code will go through a translation phase although not all
+translations will be necessarily be executed. You need to instrument
+actual executions to track what is happening.
+
+It is quite normal to see the same address translated multiple times.
+If you want to track the code in system emulation you should examine
+the underlying physical address (``qemu_plugin_insn_haddr``) to take
+into account the effects of virtual memory although if the system does
+paging this will change too.
+
+Not all instructions in a block will always execute so if its
+important to track individual instruction execution you need to
+instrument them directly. However asynchronous interrupts will not
+change control flow mid-block.
+
+Instructions
+++++++++++++
+
+Instruction instrumentation runs before the instruction executes. You
+can be can be sure the instruction will be dispatched, but you can't
+be sure it will complete. Generally this will be because of a
+synchronous exception (e.g. SIGILL) triggered by the instruction
+attempting to execute. If you want to be sure you will need to
+instrument the next instruction as well. See the ``execlog.c`` plugin
+for examples of how to track this and finalise details after execution.
+
+Memory Accesses
++++++++++++++++
+
+Memory callbacks are called after a successful load or store.
+Unsuccessful operations (i.e. faults) will not be visible to memory
+instrumentation although the execution side effects can be observed
+(e.g. entering a exception handler).
+
+System Idle and Resume States
++++++++++++++++++++++++++++++
+
+The ``qemu_plugin_register_vcpu_idle_cb`` and
+``qemu_plugin_register_vcpu_resume_cb`` functions can be used to track
+when CPUs go into and return from sleep states when waiting for
+external I/O. Be aware though that these may occur less frequently
+than in real HW due to the inefficiencies of emulation giving less
+chance for the CPU to idle.
+
 Internals
 ---------
 
-- 
2.39.2

Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>

On 1/3/24 21:33, Alex Bennée wrote:
> While we attempt to hide implementation details from the plugin we
> shouldn't be totally obtuse. Let the user know what they can and can't
> expect with the various instrumentation options.
> 
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> ---
>   docs/devel/tcg-plugins.rst | 49 ++++++++++++++++++++++++++++++++++++++
>   1 file changed, 49 insertions(+)
> 
> diff --git a/docs/devel/tcg-plugins.rst b/docs/devel/tcg-plugins.rst
> index 535a74684c5..9cc09d8c3da 100644
> --- a/docs/devel/tcg-plugins.rst
> +++ b/docs/devel/tcg-plugins.rst
> @@ -112,6 +112,55 @@ details are opaque to plugins. The plugin is able to query select
>   details of instructions and system configuration only through the
>   exported *qemu_plugin* functions.
>   
> +However the following assumptions can be made:
> +
> +Translation Blocks
> +++++++++++++++++++
> +
> +All code will go through a translation phase although not all
> +translations will be necessarily be executed. You need to instrument
> +actual executions to track what is happening.
> +
> +It is quite normal to see the same address translated multiple times.
> +If you want to track the code in system emulation you should examine
> +the underlying physical address (``qemu_plugin_insn_haddr``) to take
> +into account the effects of virtual memory although if the system does
> +paging this will change too.
> +
> +Not all instructions in a block will always execute so if its
> +important to track individual instruction execution you need to
> +instrument them directly. However asynchronous interrupts will not
> +change control flow mid-block.
> +
> +Instructions
> +++++++++++++
> +
> +Instruction instrumentation runs before the instruction executes. You
> +can be can be sure the instruction will be dispatched, but you can't
> +be sure it will complete. Generally this will be because of a
> +synchronous exception (e.g. SIGILL) triggered by the instruction
> +attempting to execute. If you want to be sure you will need to
> +instrument the next instruction as well. See the ``execlog.c`` plugin
> +for examples of how to track this and finalise details after execution.
> +
> +Memory Accesses
> ++++++++++++++++
> +
> +Memory callbacks are called after a successful load or store.
> +Unsuccessful operations (i.e. faults) will not be visible to memory
> +instrumentation although the execution side effects can be observed
> +(e.g. entering a exception handler).
> +
> +System Idle and Resume States
> ++++++++++++++++++++++++++++++
> +
> +The ``qemu_plugin_register_vcpu_idle_cb`` and
> +``qemu_plugin_register_vcpu_resume_cb`` functions can be used to track
> +when CPUs go into and return from sleep states when waiting for
> +external I/O. Be aware though that these may occur less frequently
> +than in real HW due to the inefficiencies of emulation giving less
> +chance for the CPU to idle.
> +
>   Internals
>   ---------
>