This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [PATCH -tip 0/6 V4] tracing: kprobe-based event tracer
- From: Vegard Nossum <vegard dot nossum at gmail dot com>
- To: Ingo Molnar <mingo at elte dot hu>
- Cc: Avi Kivity <avi at redhat dot com>, Masami Hiramatsu <mhiramat at redhat dot com>, "H. Peter Anvin" <hpa at zytor dot com>, Frederic Weisbecker <fweisbec at gmail dot com>, Steven Rostedt <rostedt at goodmis dot org>, Ananth N Mavinakayanahalli <ananth at in dot ibm dot com>, Andrew Morton <akpm at linux-foundation dot org>, Andi Kleen <andi at firstfloor dot org>, Jim Keniston <jkenisto at us dot ibm dot com>, kvm at vger dot kernel dot org, systemtap-ml <systemtap at sources dot redhat dot com>, LKML <linux-kernel at vger dot kernel dot org>, Pekka Paalanen <pq at iki dot fi>
- Date: Fri, 3 Apr 2009 15:16:58 +0200
- Subject: Re: [PATCH -tip 0/6 V4] tracing: kprobe-based event tracer
- References: <49D4F4B5.9040107@redhat.com> <20090403112639.GC31399@elte.hu> <49D5F80B.7000305@redhat.com> <20090403121202.GI31399@elte.hu> <49D5FE42.5080100@redhat.com> <20090403122654.GA19451@elte.hu>
2009/4/3 Ingo Molnar <mingo@elte.hu>:
>
> * Avi Kivity <avi@redhat.com> wrote:
>
>> Ingo Molnar wrote:
>>>> kvm has three requirements not needed by kprobes:
>>>> - it wants to execute instructions, not just decode them, including
>>>> Â generating faults where appropriate
>>>> - it is performance critical
>>>> - it needs to support 16-bit, 32-bit, and 64-bit instructions simultaneously
>>>>
>>>> If an arch/x86/ decoder/emulator gives me these I'll gladly switch
>>>> to it. Âx86_emulate.c is high on my list of most disliked code.
>>>>
>>>
>>> Well, this has to be driven from the KVM side as the kprobes use
>>> will only be for decoding so if it's modified from the kprobes
>>> side the KVM-only functionality might regress.
>>>
>>> So ... we can do the library decoder for kprobes purposes, and
>>> someone versed in the KVM emulator can then combine the two.
>>
>> Problem is, anyone versed in the kvm emulator will want to run as
>> far away from this work as possible.
>
> Are you suggesting that the KVM emulator should never have been
> merged in the first place? ;-)
>
> Anyway, we'll make sure the kprobes/library decoder is as clean as
> possible - so it ought to be hackable and extensible without the
> risk of permanent brain damage. Mmiotrace and kmemcheck has decoding
> smarts too, and i think the sw-breakpoint injection code of KGDB
> could use it as well - so there's broader utility in all this.
(Sorry in advance for jumping in -- my post may be irrelevant)
For the record, kmemcheck requirements for an instruction decoder are these:
For any instruction with memory operands, we need to know which are
the operands (so for movl %eax, (%ebx) we need to combine the
instruction with a struct pt_regs to get the actual address
dereferenced, i.e. the contents of %ebx), and their sizes (for movzbl,
the source operand is 8 bits, destination operand is 32 bits). For
things like movsb, we need to be able to get both %esi and %edi.
mmiotrace additionally needs to know what the actual values
read/written were, for instructions that read/write to memory (again,
combined with a struct pt_regs).
Maybe this doesn't really say much, since this is what a generic
instruction decoder would be able to do anyway. But kmemcheck and
mmiotrace both have very special-purpose decoders. I don't really know
what other decoders look like, but what I would wish for is this: Some
macros for iterating the operands, where each operand has a type (e.g.
input (for reads), output (for writes), target (for jumps), immediate
address, immediate value, etc.), a size (in bits), and a way to
evaluate the operand. So eval(op, regs) for op=%eax, it will return
regs->eax; for op=4(%eax), it will return regs->eax + 4; for op=4 it
will return 4, etc.
Both kmemcheck and mmiotrace could gain SMP support with instruction
emulation, though it is strictly not necessary. In that case, though,
we would not want to emulate fault handling, etc. (i.e. the fault
should always be generated by the CPU itself).
Please do put me on Cc for future discussions, though.
Vegard
--
"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as it
disguises that the error is the programmer's own creation."
-- E. W. Dijkstra, EWD1036