Pavel Dovgalyuk <dovga...@ispras.ru> writes:
> Peter, what about this one? > > Pavel Dovgalyuk > >> -----Original Message----- >> From: Pavel Dovgalyuk [mailto:dovga...@ispras.ru] >> Sent: Tuesday, June 05, 2018 2:56 PM >> To: 'Peter Maydell'; 'Pavel Dovgalyuk' >> Cc: 'QEMU Developers'; maria.klimushenk...@ispras.ru; 'Paolo Bonzini'; >> 'Lluís Vilanova' >> Subject: RE: [RFC PATCH v2 0/7] QEMU binary instrumentation prototype >> >> > From: Peter Maydell [mailto:peter.mayd...@linaro.org] >> > >> > This series doesn't seem to add anything to Documentation/ that >> > describes the API we make available to plugins. I'm a lot more >> > interested in reviewing the API that will be used by plugins >> > than I am in the implementation at this stage. Can you provide >> > a description/documentation of the API for review, please? >> >> >> Here is the draft: >> >> Introduction >> ============ >> >> This document describes an API for creating the QEMU >> instrumentation plugins. >> >> It is based on the following prior sources: >> - KVM Forum 2017 talk "Instrumenting, Introspection, and Debugging with >> QEMU" >> https://www.linux-kvm.org/images/3/3d/Introspect.pdf >> - Discussion on Lluis Vilanova instrumentation patch series >> https://lists.gnu.org/archive/html/qemu-devel/2017-09/msg03357.html >> >> The aim of the instrumentation is implementing different runtime >> tracers that can track the executed instructions, memory and >> hardware operations. >> >> Instrumenting the code >> ====================== >> >> Instrumentation subsystem exploits TCG helper mechanism to embed >> callbacks into the translation blocks. These callbacks may be inserted >> before the specific instructions, when the plugins require such filtering. >> >> Translator uses two functions for embedding the callbacks: >> - first function checks whether the current instruction should be >> instrumented >> - second function embeds the callback for executing the plugin-specific >> code before that instruction >> >> The similar method may be used for memory access instrumentation. >> >> QEMU->Plugin API >> ================ >> >> Instrumentation layer passes the requests from the translator >> to the dynamically loaded plugins. Every plugin may provide >> the following functions to perform the instrumentation: >> >> 1. bool plugin_init(const char *args); >> Initialization function. May return false if the plugin >> can't work in the current environment. >> >> 2. bool plugin_needs_before_insn(uint64_t pc, void *cpu); >> Returns true if the plugin needs to instrument the current instruction. >> It may use the address (pc) for making the decision or the guest >> CPU state (cpu), which can be passed back to QEMU core API >> (e.g., for reading the guest memory). >> This function is called at both translation and execution phases. >> >> 3. void plugin_before_insn(uint64_t pc, void *cpu); >> If the previous function returned true for some instruction, >> then this function will be called. This process is repeated before >> every execution of the instruction, if it was instrumented. >> >> The similar pair of functions will also be added for the memory >> operations. >> >> Plugin->QEMU API >> ================ >> >> QEMU core exports some functions to let the plugins introspect the guest >> or perform some interaction with other QEMU services (e.g., logging). >> API doesn't contain any data structures, because their memory layout depend >> on the compilation settings. >> >> QEMU exports the following functions that may be called from the plugins: >> >> 1. void qemulib_log(const char *fmt, ...); >> Wrapper for qemu_log. >> >> 2. int qemulib_read_memory(void *cpu, uint64_t addr, uint8_t *buf, int len); >> Reads guest memory into the buffer. Wrapper for cpu_memory_rw_debug. >> >> 3. int qemulib_read_register(void *cpu, uint8_t *mem_buf, int reg); >> Uses target gdb interface for accessing the guest registers. >> 'reg' is the id of the desired register as it is coded by gdb. >> >> There also should be a function for flushing the translated blocks to >> ensure that the instrumentation will occur in the case of changing >> the internal plugin state. This would certainly be the case if we could generate TCG code in the plugins. -- Alex Bennée
