Peter Maydell writes: > On 12 September 2017 at 22:01, Lluís Vilanova <vilan...@ac.upc.edu> wrote: >> This series adds an API to add instrumentation events. >> >> It also provides additional APIs for: >> * Controlling tracing events. >> * Peek/poke guest memory.
>> Future APIs (for later series): >> * Peek/poke guest registers. >> * Add breakpoints to trigger instrumentation functions. >> * Trigger instrumentation functions from guest code (former hypertrace). >> * Add events for guest code translation/execution (once the respective >> tracing >> events are accepted upstream). >> * Add events for exceptions/syscalls. >> * Add events for TB invalidation (necessary for libraries to deallocate any >> data >> they might have allocated for the TBs they instrumented). >> >> The instrumentation code is dynamically loaded as a library into QEMU either >> when it starts or later using its remote control interfaces. The loaded code >> only has access to function explicitly exported through the QI_VPUBLIC macro. >> >> This series is branch 'devel-instrument' in >> https://code.gso.ac.upc.edu/git/qemu-dbi. > To parallel the comment I sent on Emilio's series: I think the > first thing we should do here is work out the API we want to > present to the instrumentation plugin, because that's permanent > and we want to get it right. Then we can figure out the > implementation details later. > Particular notes: > * putting things in the instrumentation plugin API that basically > parallel some existing trace points is something I'm wary of, > because a lot of our existing tracing is "output something at > a point and in a way that's convenient for our internal > implementation", rather than "what is the right clean interface > to provide this sort of information". I'd rather we started > with a blank piece of paper and designed an API, and then > implemented it. Do you have an opinion on specific trace points, or an observation in general? I wanted to have the following events: * cpu hotplug/hotunplug * cpu reset * memory access translation/execution * BBL/TB translation/execution * instruction translation/execution * exceptions / syscalls > * I definitely don't think we should expose to the instrumentation > the distinction between translate time and execute time Please see my response to your email in v6. Also, I forgot an even simpler case, like instrumenting a subset of memory accesses (e.g., only writes). Thanks, Lluis