2011/12/5 Lluís Vilanova <vilan...@ac.upc.edu>: > Provides the ability for the guest to communicate with user-provided code > inside > QEMU itself, using a lightweight mechanism. > > See first commit for a full description. > > Signed-off-by: Lluís Vilanova <vilan...@ac.upc.edu> > ---
First off, thank you for your continued efforts - including the general tracing improvements you have contributed in the past. I think many people use QEMU as a tool for research and simulation, but few end up working upstream. So thanks for polishing up your work and submitting it upstream. Thoughts on the pieces you have described: > * 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. > * 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. > * 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? 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. 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? Stefan
