* Roedel, Joerg <Joerg.Roedel@xxxxxxx> wrote: > On Tue, May 10, 2011 at 11:21:32AM -0400, Ingo Molnar wrote: > > > > * Joerg Roedel <joerg.roedel@xxxxxxx> wrote: > > > > > So any feedback is greatly appreciated :-) > > > > it's nice to see this hw feature utilized :) > > Yeah, I planned to do this for some time now and finally found the time > to do it :) > > > > > > Diffstat: > > > > > > arch/x86/include/asm/perf_event.h | 3 +++ > > > arch/x86/kernel/cpu/perf_event_amd.c | 6 ++++++ > > > include/linux/perf_event.h | 5 ++++- > > > kernel/perf_event.c | 4 ++++ > > > tools/perf/util/parse-events.c | 10 +++++++++- > > > 5 files changed, 26 insertions(+), 2 deletions(-) > > > > I see you have not touched tools/perf/builtin-kvm.c - how does this feature > > integrate with the features of 'perf kvm'? (are you using perf kvm by any > > chance?) > > builtin-kvm looks like a wrapper for other perf-cmds which just sets up > some additional state to tell the sub-cmds that guest-symbols need to be > resolved and so on. > > Implementing this into the place where the other exclude-bits get set (which > is in generic code) seemed like a good idea to me. Touching builtin-kvm was > unnecessary for this. ok, then let me put it in another way: 'perf kvm' is the tool that is making Linux instrumentation friendlier to KVM developers. Can you think of ways to utilize this new feature there? For example a new 'perf kvm stat' feature could pass the exclusion bits to perf stat automatically. 'perf kvm record' could record on the guest only by default. Things like that. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
