2011/12/8 Lluís Vilanova <vilan...@ac.upc.edu>: > Stefan Hajnoczi writes: > [...] >>> * Support for tracing guest code through TCG. > >> I'm not clear on whether a backdoor mechanism is needed or not. A >> backdoor mechanism allows a modified guest to participate in tracing. > >> Depending on the type of analysis you are doing it might be possible >> to achieve the same thing by emitting calls to custom instrumentation >> in TCG (or is this too low-level for what you're trying to trace in >> the guest?). The advantage is also that you can do this to unmodified >> guests. > > You're right with the first; it exists for two reasons: > > * simplicity: it's easier to have, for example, a backdoor + linux tracepoints > than obtaining the IP of an "interesting" function (think of the > multiprogramming on a full system) > > * performance: it's faster to let the guest tell you rather than (ab)using > breakpoints or checking the IP of every instruction
I still think that a breakpoint based system could be a useful method in addition to others, simply because it is entirely invisible to the guest and can then be used with unmodified and non-cooperating guests. Properly implemented, it should not have much overhead. > The main use of this is to get semanticful events on the guest (my previous > example was about knowing when linux changes the current process, but you > could > use anything else as well - e.g., a certain function of a specific thread on > the > guest -). > > >>> * Support for different sets of enabled guest tracing events on a per-vCPU >>> basis. > >> This feature is very specific but potentially useful. I haven't >> reviewed patches yet but I can imagine that this would be merged. > > I'll send it after the initial TCG tracing support. > > >>> * Support for instrumenting tracing events (including those for guest code). > >> Although I typically use post-processing rather than filtering, I can >> see your point about the power and flexibility in being able to react >> on the spot to events inside QEMU. Given the ad-hoc nature of the >> instrumentation, as well as that this is really in the guts of QEMU >> and TCG, I think we should make it easy to write instrumentation but >> keep the infrastructure and APIs minimal. > >> Is there even a need to add "instrumentation" support on top of QEMU >> tracing? As an instrumentation implementor you are working with the >> QEMU source tree and need to be somewhat familiar with the internals. >> Why not just add custom functions into QEMU and call them from >> relevant points? > > Well, the point is to just use the existing tracing points in QEMU. Of > course, I > could just modify tracetool and add support for a new tracing backend that > uses > my library. > > The intention was just to make it brain-dead simple and repeatable (no manual > editing of the auto-generated tracing files), as well as able to reuse > existing > backends when the user sees fit. > > >> The documentation and tracetool extensions you posted provide some >> structure but IMO they don't cut down the workflow significantly over >> adding plain old functions in places of interest. i.e. by the time I >> have read the docs and begun trying to add instrumentation I could >> have already added a custom function in QEMU and built a binary. Plus >> it's harder to understand/debug instrumentation code if it sits on top >> of the tracing instrumentation - yet another layer to understand. > > True. Maybe an unofficial [1] instrumentation tracing backend would be simpler > to use and maintain. > > [1] I'm assuming from Anthony's comments that such a thing would not be > accepted > upstream. > > >> So I'm suggesting that we don't *need* explicit support for >> instrumenting trace events. Instead add plain old functions where you >> need them. You may decide to invoke trace events from your >> instrumentation function, but that's already covered today by >> docs/tracing.txt. > >> Am I missing the point of instrumentation tracing events or do you >> agree that we can work well without it? > > The point is to avoid diving into QEMU's code and instead use the current > out-of-the-box tracing points as the instrumentation hooks, which can be > achieved both through the current approach or an unofficial tracing backend. > > The nice thing about the current approach is that the user can do some extra > checks on the tracing event and then (maybe) call the original > backend-generated > tracing routine (as a quick and easy way to extend what to actually trace). Tracepoints shouldn't also suffer from bit rot so easily. > > > Lluis > > -- > "And it's much the same thing with knowledge, for whenever you learn > something new, the whole world becomes that much richer." > -- The Princess of Pure Reason, as told by Norton Juster in The Phantom > Tollbooth