instruction-analysis API(s)

[Ananth N Mavinakayanahalli]

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