On Tue, 2009-02-10 at 10:12 +0530, Ananth N Mavinakayanahalli wrote: > On Mon, Feb 09, 2009 at 06:05:56PM -0500, Masami Hiramatsu wrote: > > 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 > > Right, that surely sounds like the way to go. However, we've been > cautioned that the instruction emulation area of the kvm code is very > performance sensitive. But, there is no harm in prototyping the above > and then worrying about any optimizations so there isn't a performance > issue -- in any case, I guess [ku]probes are very infrequent users of > this compared to KVM. > > Ananth
Hi, Masami. Ananth, Srikar, Maneesh, and I talked about this last night. While I was on vacation, Srikar did further investigation into adapting x86 kvm's instuction analysis for more general use, and he's not optimistic. For the short term, at least (i.e., between now and the Linux Foundation Collaboration Summit in April), we're going to proceed based on the prototype I developed. As you noted, djprobes needs instruction lengths, and my prototype doesn't provide that info. (Uprobes computes instruction lengths for rip-relative x86_64 instructions, but that's only a subset of what you need.) Are you interested in extending/enhancing my prototype to make it useful for djprobes? If so, I'd be happy to consult. Thanks. Jim
