instruction-analysis API(s)

[Masami Hiramatsu]

Jim Keniston wrote:
> 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.

Here are a patch against your code and an example code for
instruction length decoder.
Curiously, KVM's instruction decoder does not completely
cover all instructions(especially, Jcc/test...).
I had to refer Intel manuals.

Moreover, even with this patch, the decoder is incomplete.
- this doesn't cover 3bytes opcode yet.
- this doesn't decode sib, displacement and immediate.
- might have some bugs :-(


Thank you,

-- 
Masami Hiramatsu

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

e-mail: mhiramat at redhat.com

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: insn_x86.patch
URL: <http://listman.redhat.com/archives/utrace-devel/attachments/20090227/0e11f8e8/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: insndec.c
URL: <http://listman.redhat.com/archives/utrace-devel/attachments/20090227/0e11f8e8/attachment.c>