3 ms·

Unicorn is a massive patch on top of QEMU 2.2 [1] that approximately does the following: - Removes a couple of architectures (because they're not supported yet

Unicorn is a massive patch on top of QEMU 2.2 [1] that approximately does the following: - Removes a couple of architectures (because they're not supported yet for hooks/register access). - Removes hardware support, as well as the qemu-system and qemu-user targets. - Modifies the JIT and all supporting APIs to not use globals. This allows you to compile JIT support for more than one guest architecture into the same binary, as well as run more than one instance of the JIT at once (so you can emulate two CPUs in parallel, even of different architectures). - Adds a hook infrastructure to call callback function(s) with metadata on many different events, including memory access, memory fault, interrupt, basic block entry, instruction execution (so like per instruction address). These calls are inserted into the JIT stream only when you add a hook, so they're reasonably efficient. - Adds register read/write APIs (this is actually a ton of code in the form of a switch/case table for each arch) - Exposes all of this using a simple C library / API: uc_open(arch, mode) uc_mem_map() uc_mem_write/read() uc_reg_write/read() uc_emu_start/stop() uc_hook_add/del() [1] I'm currently porting it to QEMU 2.5 because I need one new ARM NEON instruction. This is probably overkill, but it's a good cause.

cm3 11y ago
Thanks for the detailed explanation. Does that mean it's not a replacement for QEMU and not intended to be? Regarding qemu-user and qemu-system, I've had bad luck with it all the time. In 2.5-rc2 I got qemu-system-x86_64 but when I build 2.5 with the same configure flags, I don't get qemu-system-x86_64 at all. You wouldn't happen to know how to work around that, would you? As I use it just for kvm functionality for vms, I configure it like this, but qemu-2.5 final's build system seems to be broken. --target-list=x86_64-linux-user --enable-pie --enable-seccomp --enable-curses The last known version that was able to build qemu-system-x86_64 is 2.4.92. Any idea?
- lunixbochs 11y ago
  1) It really depends on the features of QEMU you use. Unicorn and friends could eventually support every feature of QEMU, but currently are nowhere near that. Usercorn should be able to replace qemu-user eventualy. 2) You should really go to the QEMU team for support on that.
  - cm3 11y ago
    2) Seems like the configure (and/or build) script was broken at some point. Letting it build all targets does not omit the amd64 kvm executable. 1) But I don't really understand the end goal if you're always forking of the next qemu relese to patch stuff back in. Is there no interest in qemu upstream for those features? I've seen it for the first time 2.6-rc, so is qapi some kind of API you might adapt or is it too limited?
    - lunixbochs 11y ago
      At this point Unicorn is a hard fork with a very specific goal. It accomplishes this goal much better than upstream QEMU. I believe combined TCG / no-globals should be upstreamed (I think I actually saw commits in 2.5 about supporting multiple architectures in one QEMU binary?), but I don't know if anyone working on Unicorn has talked to anyone upstream about this. I believe Unicorn also contains QEMU bugfixes. To me, in an ideal world, we might have something like this: libqemu-cpu - Basically Unicorn. C library/API to easily create/hook/manipulate one or more CPUs. libqemu-system - All hardware/peripheral support from QEMU. Attach any component(s) to a supported CPU at runtime. libqemu-user - The current qemu-user, except as a library with syscall/whatever hooking support. There'd probably be a good amount of code generation here.

cm3 11y ago

Thanks for the detailed explanation. Does that mean it's not a replacement for QEMU and not intended to be? Regarding qemu-user and qemu-system, I've had bad luck with it all the time. In 2.5-rc2 I got qemu-system-x86_64 but when I build 2.5 with the same configure flags, I don't get qemu-system-x86_64 at all. You wouldn't happen to know how to work around that, would you? As I use it just for kvm functionality for vms, I configure it like this, but qemu-2.5 final's build system seems to be broken. --target-list=x86_64-linux-user --enable-pie --enable-seccomp --enable-curses The last known version that was able to build qemu-system-x86_64 is 2.4.92. Any idea?

lunixbochs 11y ago
1) It really depends on the features of QEMU you use. Unicorn and friends could eventually support every feature of QEMU, but currently are nowhere near that. Usercorn should be able to replace qemu-user eventualy. 2) You should really go to the QEMU team for support on that.
- cm3 11y ago
  2) Seems like the configure (and/or build) script was broken at some point. Letting it build all targets does not omit the amd64 kvm executable. 1) But I don't really understand the end goal if you're always forking of the next qemu relese to patch stuff back in. Is there no interest in qemu upstream for those features? I've seen it for the first time 2.6-rc, so is qapi some kind of API you might adapt or is it too limited?
  - lunixbochs 11y ago
    At this point Unicorn is a hard fork with a very specific goal. It accomplishes this goal much better than upstream QEMU. I believe combined TCG / no-globals should be upstreamed (I think I actually saw commits in 2.5 about supporting multiple architectures in one QEMU binary?), but I don't know if anyone working on Unicorn has talked to anyone upstream about this. I believe Unicorn also contains QEMU bugfixes. To me, in an ideal world, we might have something like this: libqemu-cpu - Basically Unicorn. C library/API to easily create/hook/manipulate one or more CPUs. libqemu-system - All hardware/peripheral support from QEMU. Attach any component(s) to a supported CPU at runtime. libqemu-user - The current qemu-user, except as a library with syscall/whatever hooking support. There'd probably be a good amount of code generation here.