Blue Swirl writes: > 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. Yup. My plan was to implement this sometime in the future :) On the performance side, there's only the degenerated case of a very hot code page that repeatedly triggers false mmu faults due to the (never reached) breakpoint. As for simplicity, I can use the backdoor to tell my analuzer to insert a breakpoint in the given address, instead of having some complex system to get symbol information from the outside (specially in softmmy mode). [...] >>> 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. Exactly. That's why I thought that tracepoint instrumentation is not such a bad option. 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
