On Fri, Apr 8, 2011 at 1:11 PM, Jan Kiszka <jan.kiszka@xxxxxxxxxxx> wrote: > On 2011-04-08 10:27, Pekka Enberg wrote: >> Hi Jan, >> >> On Fri, 2011-04-08 at 09:39 +0200, Jan Kiszka wrote: >>> I agree that it's easy to change 2kSomething LOC for this. But if you >>> now wait too long designing in essential features like SMP, a scalable >>> execution model, and - very important - portability (*), it can get >>> fairly painful to fix such architectural deficits later on. How long did >>> it take for Linux to overcome the BKL? QEMU is in the same unfortunate >>> position. >> >> Yup, and we're taking your feedback seriously (and are thankful for >> it!). We're hoping to look at SMP in the near future - help is >> appreciated! > > Honestly, I do not yet see a major advantage for us to invest here > instead of / in addition to continuing to improve QEMU. We've spend > quite some effort on the latter with IMO noteworthy results. Porting > over qemu-kvm to upstream was and still is among those efforts. We (*) > are "almost done". :) > > Just one example: Despite QEMU's current deficits, I just have add a > handful of (ad-hoc) patches to turn it into a (soft) real-time > hypervisor, and that also for certain non-Linux guests. Your approach is > yet man years of development and stabilization effort away from getting > close to such a level. > > Don't want to discourage you or other contributors. I wish you that this > approach can gather the critical mass and momentum to make it a real > alternative, at least for a subset of use cases. We will surely keep an > eye on it and re-assess its pros&cons as it progresses. > > Jan > > (*) the QEMU & KVM community > > -- > Siemens AG, Corporate Technology, CT T DE IT 1 > Corporate Competence Center Embedded Linux > It seems there is a misunderstanding. KVM-tool is quite far from been KVM replacement (if ever). And what we're doing -- extremely tiny/small HV which would help us to debug/test kernel code. So I personally think of two scenarios: 1) QEMU eventually get merged upstream and kvm-tool remains small and tiny example of how to do /dev/kvm ioctls with some positive (I hope) results. Or maybe kvm-tool gets dropped since nobody needs it, this is possible too of course. 2) kvm-tool silently sit in tools/kvm while qemu remains on separated repo. Both go own ways. Not a pleasant scenario but still possible. And we don't consider kvm-tool as a qemu competitor by any means. It simply different weight categories. And of course we're glad to get any feedback (and positive and especially negative). Pointing out that SMP might be such a problem made us scratching the head ;) -- 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
