| tcg-plugins.rst (b0b3c0f56258b697dd3faca389e98d0022bc7727) | tcg-plugins.rst (f87b220f2a9d6a552c4cd2004475e76f38a08279) |
|---|---|
| 1.. 2 Copyright (C) 2017, Emilio G. Cota <cota@braap.org> 3 Copyright (c) 2019, Linaro Limited 4 Written by Emilio Cota and Alex Bennée 5 6.. _TCG Plugins: 7 8QEMU TCG Plugins --- 98 unchanged lines hidden (view full) --- 107 108The plugin architecture actively avoids leaking implementation details 109about how QEMU's translation works to the plugins. While there are 110conceptions such as translation time and translation blocks the 111details are opaque to plugins. The plugin is able to query select 112details of instructions and system configuration only through the 113exported *qemu_plugin* functions. 114 | 1.. 2 Copyright (C) 2017, Emilio G. Cota <cota@braap.org> 3 Copyright (c) 2019, Linaro Limited 4 Written by Emilio Cota and Alex Bennée 5 6.. _TCG Plugins: 7 8QEMU TCG Plugins --- 98 unchanged lines hidden (view full) --- 107 108The plugin architecture actively avoids leaking implementation details 109about how QEMU's translation works to the plugins. While there are 110conceptions such as translation time and translation blocks the 111details are opaque to plugins. The plugin is able to query select 112details of instructions and system configuration only through the 113exported *qemu_plugin* functions. 114 |
| 115However the following assumptions can be made: 116 117Translation Blocks 118++++++++++++++++++ 119 120All code will go through a translation phase although not all 121translations will be necessarily be executed. You need to instrument 122actual executions to track what is happening. 123 124It is quite normal to see the same address translated multiple times. 125If you want to track the code in system emulation you should examine 126the underlying physical address (``qemu_plugin_insn_haddr``) to take 127into account the effects of virtual memory although if the system does 128paging this will change too. 129 130Not all instructions in a block will always execute so if its 131important to track individual instruction execution you need to 132instrument them directly. However asynchronous interrupts will not 133change control flow mid-block. 134 135Instructions 136++++++++++++ 137 138Instruction instrumentation runs before the instruction executes. You 139can be can be sure the instruction will be dispatched, but you can't 140be sure it will complete. Generally this will be because of a 141synchronous exception (e.g. SIGILL) triggered by the instruction 142attempting to execute. If you want to be sure you will need to 143instrument the next instruction as well. See the ``execlog.c`` plugin 144for examples of how to track this and finalise details after execution. 145 146Memory Accesses 147+++++++++++++++ 148 149Memory callbacks are called after a successful load or store. 150Unsuccessful operations (i.e. faults) will not be visible to memory 151instrumentation although the execution side effects can be observed 152(e.g. entering a exception handler). 153 154System Idle and Resume States 155+++++++++++++++++++++++++++++ 156 157The ``qemu_plugin_register_vcpu_idle_cb`` and 158``qemu_plugin_register_vcpu_resume_cb`` functions can be used to track 159when CPUs go into and return from sleep states when waiting for 160external I/O. Be aware though that these may occur less frequently 161than in real HW due to the inefficiencies of emulation giving less 162chance for the CPU to idle. 163 |
|
| 115Internals 116--------- 117 118Locking 119~~~~~~~ 120 121We have to ensure we cannot deadlock, particularly under MTTCG. For 122this we acquire a lock when called from plugin code. We also keep the --- 479 unchanged lines hidden --- | 164Internals 165--------- 166 167Locking 168~~~~~~~ 169 170We have to ensure we cannot deadlock, particularly under MTTCG. For 171this we acquire a lock when called from plugin code. We also keep the --- 479 unchanged lines hidden --- |