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

[Andi Kleen <andi at firstfloor dot org>]

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.

> 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? 

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

What were the problems?

Did you report the problems to the KVM maintainers?

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

> So soon, I had to rewrite it based on Intel's manual entirely :-(

Ok then perhaps KVM could benefit from your work too?

> > 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.

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only.