Re: [PATCH -tip 0/6 V4] tracing: kprobe-based event tracer

[Vegard Nossum <vegard.nossum@gmail.com>]

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