3 ms·
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
by 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 agoAt 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.