On Fri, Oct 22, 2010 at 6:32 PM, Lluís <xscr...@gmx.net> wrote: > Here's a set of patches with the current state of static > instrumentation. > > Hope that this organization will help understanding the point of > it. Patch 9 describes the taken approach for instrumenting during code > generation, which is the main point of this.
The patches are now more readable, thanks for the effort. > Code can also be reached at: > https://projects.gso.ac.upc.edu/projects/qemu-instrument > https://code.gso.ac.upc.edu/git/qemu-instrument > > Lluís Vilanova (17): > backdoor: Declare host-side backdoor helpers > backdoor: [all] Include backdoor helper declarations > backdoor: Declare guest-side interface macros > backdoor: [i386] Decode backdoor instructions > backdoor: [i386] Declare guest-side interface macros > backdoor: Add a simple example The backdoor instruction is problematic. For example, handling that in KVM may be difficult and there are guest visible side effects. The same effect can be achieved with a MMIO/PIO device or instrumented breakpoints/watchpoints. For the MMIO/PIO device solution, there are several PV devices available, for example virtio devices and fw_cfg. Instead of a backdoor instruction, the guest should simply issue MMIO or PIO using regular instructions. For Linux user, a new syscall can be added. Anyway, the guest still needs to be modified. Instrumenting GDB watchpoint and/or breakpoint support would be more attractive because this would be completely invisible to the guest and it may be controlled from GDB. > instrument: Handle config-time activation > instrument: Add initial instrumentation example > instrument: Dynamic per-CPU state of static instrumentation points > instrument: Code-generation macros > instrument: [all] Include instrumentation helper declarations > instrument: Add FETCH point > instrument: [i386] Call FETCH point > instrument: Add VMEM point > instrument: [all] Call VMEM point > instrument: Add PLVL point > instrument: [i386] Call PLVL point At least in these examples, the instrumentation code just prints out a few interesting fields, so they are almost identical to tracepoints. The general approach seems to be that when an interesting event happens, call the instrumentation code directly. A lot of internal state needs to be made available to the instrumentation code, which is a problem if that is considered as an API. Perhaps this could be changed so that when the event happens, the only effect is that the VM is stopped with some kind of notification. Then a controlling application (external to QEMU) can inspect the state and enable/disable tracepoints as it wishes, but using only the tools that are available for tracepoints, QMP or GDB. Performance would be much lower, though.
