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.
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. > > I decided to survey the kernel for subsystems that parse and/or analyze > CPU instructions. I hoped to review the various approaches -- perhaps > finding one that's widely accepted -- and to evaluate possible clients > for our instruction-analysis service. > > The results were discouraging, as summarized below. I see no > promise of an architecture-agnostic instruction-analysis API. > Within each architecture, I think the best we could do would be an > (architecture-specific) instruction-parsing API. (And even within > an architecture, different subsystems look at different aspects of > an instruction.) > > 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 > > Intro > ----- > "Instruction analysis" refers to the analysis of a CPU instruction > in the kernel or a user program. Typically, the instruction must > be analyzed so that it can be properly emulated (in the case of > SSOL, by executing the same instruction at a different address), > or so a fault caused by the instruction can be properly handled. > There are other uses as well -- see below. > > Possible Clients of an Instruction-Analysis Service > --------------------------------------------------- > Where in the kernel is instruction analysis currently used? > - kprobes (arm, avr32, ia64, mn10300, powerpc, s390, sh, sparc, x86) > - uprobes (ia64, powerpc, s390, x86) > - hypervisors: > - kvm (ia64, powerpc, s390, x86) > - powerpc Cell Beat hypervisor > - floating-point unit emulation (arm, s390, sparc, x86) > - exception handling: > - page fault (powerpc, x86) > - illegal instruction (s390) > - unaligned trap (ia64) > - vm86 fault (x86) > - disassembly (powerpc, s390) > - powerpc: xmon, code patching (for crash dump?) > - ia64: emulation of brl instruction > - x86: alternative-instruction patching (replacing instructions that are > inappropriate for the CPU rev), fault injection > - djprobes (not in kernel, not sure of status) > > Note: I looked in detail only at the architectures that implement > kprobes: arm, avr32, ia64, mn10300, powerpc, s390, sh, sparc, and x86. > And I note in passing that sh does a lot of instruction analysis -- > as does mips -- but I skipped sh for now. > > Note: Roland also listed gdb, perfmon, and ftrace as subsystems that > do instruction analysis. I think that oprofile has also been suggested. > - I haven't investigated gdb, but I have no reason to think Roland is > wrong about it. > - I've looked briefly at the various components of perfmon[2] and > oprofile, but I don't see any instruction analysis per se; and the > perfmon/oprofile expert I asked (IBM's Carl Love) isn't aware of any. > - Similarly, I don't see instruction analysis per se in ftrace. > > Prospects/Problems > ------------------ > What are the prospects for adapting these various subsystems to use > a common instruction-analysis service? Typically, not very good. > Here are some of the problems: > - Different architectures have very different instruction-analysis > needs. > - Different architectures have very different instruction formats and > instruction attributes. Consequently, the opportunities for common > code shared by multiple architectures are few. > - Different subsystems are interested in different instruction > attributes, and/or classify instructions differently. > - Some subsystems are interested in only certain instructions. > - Some subsystems, such as fault handlers, want to maximize efficiency > by examining as little of the instruction as possible; while others, > such as *probes, take a more leisurely approach (e.g., reading enough > bytes to capture the largest possible instruction, even if that means > faulting in a page). > -- Masami Hiramatsu Software Engineer Hitachi Computer Products (America) Inc. Software Solutions Division e-mail: mhira...@redhat.com
