Re: [PATCH -tip 0/4 V3] tracing: kprobe-based event tracer

Re: [PATCH -tip 0/4 V3] tracing: kprobe-based event tracer

[Masami Hiramatsu]

Andi Kleen wrote:
> On Wed, Apr 01, 2009 at 07:21:55PM -0400, Masami Hiramatsu wrote:
>> Andi Kleen wrote:
>>> On Wed, Apr 01, 2009 at 04:51:00PM -0400, Masami Hiramatsu wrote:
>>>> Andi Kleen wrote:
>>>>> Masami Hiramatsu <mhiramat@redhat.com> writes:
>>>>>> I agreed. Fortunately, Jim Keniston and I wrote an x86 instruction
>>>>>> decoder :-) which has been made originally for uprobe andd kprobes
>>>>>> jump-optimizer.
>>>>>>
>>>>>> https://www.redhat.com/archives/utrace-devel/2009-March/msg00031.html
>>>>> An alternative would be to adapt the x86 interpreter in KVM.
>>>>> I thought for some time that that one should be available in 
>>>>> a more generic form in a library.
>>>> As far as I can see, KVM's instruction emulator is incomplete
>>> That's fine for you -- you only care about a subset of instructions
>>> anyways, don't you?
>> Actually, (in my case) I just need to decode non-FPU instructions,
> 
> What does it have to do with the FPU?  I don't think the KVM
> one is aimed at those either.

Nothing, at least in kernel :). However, as I said before,
uprobe developers want to use this decoder for decoding
FPU instructions. Fortunately, this decoder can cover
those instructions too.

>> because I'd like to check whether kprobe is on the instruction
>> boundary.
>>
>> However, KVM's insn decoder can't decode some elemental
>> instructions, and instruction flags are incorrect.
> 
> What flags?  EFLAGS? 

No, KVM's decoder has instruction classification flags for
each instructions, and some of those flags are not correct.

>> I had written instruction decoder based on it, but the result
>> was so awful!
> 
> What were the problems?

It couldn't decode kernel binary correctly and found many bugs...

https://www.redhat.com/archives/utrace-devel/2009-March/msg00013.html

On the other hand, this decoder already verified that the result
is same as objdump's output.

https://www.redhat.com/archives/utrace-devel/2009-March/msg00031.html


> Did you report the problems to the KVM maintainers?

No, sorry, because I wrote a patch just referring KVM decoder.
I didn't use KVM decoder code itself.
I guess KVM uses their decoder only for emulating a
limited number of instructions. In that case, it will be OK for KVM.


> I still think it would be better to have a single good
> decoder than a multitude of different ones tailored to specific
> cases. 

Sure, why not? I agreed we'd better have a single decoder in the end.
However, I think KVM decoder is too big and complex (and tailored?)
to start with...
So, IMHO, we'd better have a "transition period" to clarify
demands from user components, to discuss how we can integrate it.

>> So soon, I had to rewrite it based on Intel's manual entirely :-(
> 
> Ok then perhaps KVM could benefit from your work too?

If their purpose is covering all instructions, Yes.

>>> do nothing. I looked at it some time ago for doing instruction
>>> length checking for some application, but that application
>>> then disappeared. The main obstacle with making it a library 
>>> is that some KVM specific dependencies have crept in that would
>>> need to be abstracted again, but I don't think it would need a lot of 
>>> effort,
>> Sorry, but I don't think so. Current KVM's decoder is much more
>> focusing on preparing instructions emulation. It requires
>> vcpu setup, fetching operators and so on. I think it needs to
>> diet their code (or well splitting from emulator).
> 
> the vcpu stuff can be all dummies. If you look at the original
> Xen version of it before it forked it was better isolated there.
> The other stuff that crept in in the KVM version could be also
> fixed.
> 
> 
>> Anyway, I don't stick with my decoder. If they can provide more
>> generic interfaces, I'd be happy to use it. :-)
> 
> I suspect "they" would need some help.

Sure, I agreed.

KVM developers, I'll cross-post our x86 instruction decoder to
KVM-ML. If you are interested in, please comment on it :)

Thank you,


-- 
Masami Hiramatsu

Software Engineer
Hitachi Computer Products (America) Inc.
Software Solutions Division

e-mail: mhiramat@redhat.com