Peter Maydell writes: > On 26 July 2017 at 12:26, Stefan Hajnoczi <stefa...@redhat.com> wrote: >> On Tue, Jul 25, 2017 at 02:30:06PM +0100, Peter Maydell wrote: >>> Is your proposal that my-instrumentation.c gets compiled into >>> QEMU at this point? That doesn't seem like a great idea to >>> me, because it means you can only use this tracing if you >>> build QEMU yourself, and distros won't enable it and so >>> lots of our users won't have convenient access to it. >>> I'd much rather see a cleanly designed plugin interface >>> (which we should be able to implement in a manner that doesn't >>> let the plugin monkey patch arbitrary parts of QEMU beyond >>> what can already be achieved via LD_PRELOAD). >> >> Trace events are not a stable public API. They change between releases >> and need to be interpreted together with the QEMU source code. >> >> It doesn't make sense to be doing instrumentation inside the QEMU >> process but not want to compile QEMU. >> >> What is the use case?
> I want the continuous stream of people who come along > and want to do interesting things (or even just straightforward > things like "show me all the memory accesses") with tracing > their guest binary to be able to do so without having to > rebuild QEMU. We don't require people to rebuild QEMU > themselves to attach gdb to it, and tracing of guest > behaviour is a similar "I just want to introspect what > my guest is doing" use case. > I think this is distinct from use of the trace API > for qemu-internal events as used in a lot of the C > code. > Some simple use cases: > * a plugin which prints out instruction execution traces > by hooking into "insn executed" and printing something > helpful (you can extend this into producing traces > in whatever standard format some other program wants > to inhale, but at a minimum it would be something we > could point people at that makes more sense than our > current "only print insns at translate time" debug); > it's also easy to add bells and whistles for "start > tracing at time T" and so on > * a plugin that make cachegrind-style guesses about > cache usage by tracking memory accesses and simulating > cache effects > * a plugin that prints all the system calls the > guest makes (by hooking into "insn executed" and > printing info when the insn is an SVC) > * trivial statistics like "count executed instructions > and branches taken" > (I also think that we should aim for that API for > things like guest register changes and guest memory > changes to not be particularly unstable even if we > allow ourselves to make non-back-compatible changes > to it.) That's what I was thinking about (i.e., try to keep a minimally useful and stable set of guest_* tracepoints). And I guess this also answer's Stefan's other email about instrumentation use-cases. Cheers, Lluis