Jim Keniston wrote: > On Fri, 2009-02-06 at 15:49 -0500, Masami Hiramatsu wrote: >> Hi Jim, >> >> I'm also interested in the instruction decoder. >> If you don't mind, could we share the API specification? >> I'd like to port djprobe on it. > > I'm enclosing the little x86 instruction-analysis protoype I hacked > together (insn_x86.*), along with a copy of systemtap's > runtime/uprobes2/uprobes_x86.c, which I modified to use it.
Hmm, actually, djprobe needs both of the length and the type of instructions, since it has to know how many bytes must be copied and be replaced by a long jump. > But again, we haven't really settled on an API. For example, my x86 > prototype doesn't collect all the info that kvm needs. We're thinking > that adapting some existing code (like kvm in the x86 case) might be > more palatable to LKML. Sure, since kvm and emulators have to fetch the values of src/dst for the emulation, they need actual register values. On the other hand, the disasm/*probe have to analysis code before hitting, so they don't know the actual value of the registers. So, I think we should split x86_decode_insn() into 2 parts, static analysis and emulation preparation. For example: 1) analyzing code statically (x86_analyze_insn) - just decoding an instruction - this phase may consist of several sub-functions. 2) preparing emulation (x86_evaluate_insn) - evaluating src/dst based on current(vcpu) registers 3) executing emulation (x86_emulate_insn) - emulating an analyzed instruction Thanks, > > Jim > >> Thanks! >> >> Jim Keniston wrote: >>> Hi, Roland. Back in a conference call in December, we discussed >>> approaches to refactoring utrace-related code such as uprobes, to >>> make some of the services provided there more generally available. >>> In particular, you suggested an "instruction analysis" service that >>> various subsystems could exploit -- kprobes and uprobes/ubp at first, >>> and eventually perhaps gdb, perfmon, kvm, ftrace, and djprobes. >>> > ... >>> Srikar Dronamraju and I are exploring two different approaches to an >>> x86 instruction-parsing service. Since x86 kvm seems to have one of >>> the most systematic and thorough approaches, Srikar is prototyping a >>> generalization of kvm's x86_decode_insn() to make it support kprobes, >>> and eventually uprobes. (Note that kvm does NOT appear to be a good >>> starting place on powerpc and s390.) Approaching from the minimalist >>> side, I've implemented an x86 instruction-parsing API with just enough >>> smarts (so far) to support kprobes and uprobes. >>> >>> We'd be interested to know whether these efforts are consistent >>> with what you have in mind. >>> >>> See more details below. >>> >>> Jim > ... > -- Masami Hiramatsu Software Engineer Hitachi Computer Products (America) Inc. Software Solutions Division e-mail: mhira...@redhat.com
