3 ms·

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 l

by 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.

by cm3 11y ago

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.