Avi Kivity wrote: > Ingo Molnar wrote: >> ok, the structure and concept looks quite good now, really nice! >> >> I'm wondering about something i suggested many moons ago: to look into >> the KVM decoder+emulator (arch/x86/kvm/x86_emulate.c). >> >> I remember there were some issues with that (one problem being that >> the KVM decoder is a special-purpose thing covering specific range of >> execution environments - not a near-full integer-ops decoder like the >> one we are aiming for here) - are there any other fundamental problems >> beyond 'it has to be done' ? >> >> Conceptually we want just a single piece of decoder logic in >> arch/x86/. If the KVM folks are cool with it we could factor out the >> KVM one into arch/x86/lib/. But ... if there are compelling reasons to >> leave the KVM one alone in its limited environment we can do that too. >> > > kvm has three requirements not needed by kprobes: > - it wants to execute instructions, not just decode them, including > generating faults where appropriate > - it is performance critical > - it needs to support 16-bit, 32-bit, and 64-bit instructions > simultaneously Hmm, I'd like to know actually kvm aims to emulate all kinds of instructions. If so, I might find some bugs in x86_emulate.c. However, I don't know all bugs. To find all of them, we have to port x86_emulate.c to user-space, decode binaries with it, and compare its output with another decoder, as Jim had done with insn.c. https://www.redhat.com/archives/utrace-devel/2009-March/msg00031.html Thank you, -- Masami Hiramatsu Software Engineer Hitachi Computer Products (America) Inc. Software Solutions Division e-mail: mhiramat@xxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
