Jim Keniston wrote: [...] > Possible Clients of an Instruction-Analysis Service > --------------------------------------------------- > Where in the kernel is instruction analysis currently used?
I think we also need to clarify why they need it(what information/action they require), because it defines API. > - kprobes (arm, avr32, ia64, mn10300, powerpc, s390, sh, sparc, x86) > - uprobes (ia64, powerpc, s390, x86) > - djprobes (not in kernel, not sure of status) They need 'static' analysis of instructions to get below parameters. - length - attribute (prefixes, etc) - type (jump/accumulation/memory access/flag change, etc) > - hypervisors: > - kvm (ia64, powerpc, s390, x86) > - powerpc Cell Beat hypervisor > - floating-point unit emulation (arm, s390, sparc, x86) They need 'dynamic' instruction emulation. > - exception handling: > - page fault (powerpc, x86) > - illegal instruction (s390) > - unaligned trap (ia64) > - vm86 fault (x86) Depends on the case, however, some of them just need instruction type and length, and these should be done very quickly. So, they need a light-weight and specialized analyzer/emulator. > - disassembly (powerpc, s390) > - powerpc: xmon, code patching (for crash dump?) Maybe, static analysis is enough? > - ia64: emulation of brl instruction Dynamic emulation. > - x86: alternative-instruction patching (replacing instructions that are > inappropriate for the CPU rev), fault injection Static analysis. [...] > 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. IMHO, there are just need two types of interfaces: static analyzer or dynamic emulator. > - 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. Indeed. I think we don't need to care all of them at the start point. Just starting simply and evolving code on upstream is my recommendation. > - 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). Indeed. I think those efficiency-required subsystems are so arch-dependent that we can (just) shares instruction bitmaps or provide special interfaces. Thank you for your work! -- Masami Hiramatsu Software Engineer Hitachi Computer Products (America) Inc. Software Solutions Division e-mail: mhira...@redhat.com
