Am 07.01.2011 20:10, Gleb Natapov wrote: >>>> We are on a good track now. I predict that we will be left with only one >>>> or two major additional features in qemu-kvm in a few months from now, >>>> no more duplications with subtle differences, and production-grade kvm >>>> upstream stability. >>>> >>> You are optimistic. My prediction is that it will take at least one major RHEL >>> release until such merged code base will become production-grade. That >>> is when most bugs that were introduced by eliminating subtle differences >>> between working and non-working version will be found :) >> >> The more upstream code qemu-kvm stresses, the faster this convergence >> will become. And there is really not that much left. E.g, I've a >> qemu-kvm-x86.c here that is <400 LOC. >> > That's what I don't get. Why working qemu-kvm should stress non working > upstream code? Just remove upstream code and replace it with qemu-kvm > version. We are 3/4 (if not more) done with refactoring qemu-kvm into a clean state, removing lots of cruft from libkvm days and early kvm modules. We achieved this by creating a "fork of the fork": upstream kvm. We may argue a lot about pros and cons of this approach, but it is a fact now. And a lot of effort would be wasted as well by throwing this away. Moreover, taking off the x86 glasses: ppc and s390 rely on upstream kvm. So it is impossible to drop those bits without breaking all non-x86 kvm archs. > >>> >>> BTW Do you have a plan how to move upstream to thread per vcpu? >> >> Upstream has this already, but it's - once again - a different >> implementation. Understanding those differences is one of the next steps. >> > I see only two threads on upstream no matter how much vcpus I configure. /me sees a lot of them. Did you enable io-thread support? Otherwise kvm is run just like tcg in single-thread mode. > >> In fact, as posted recently, unifying the execution model >> implementations is the only big problem I see. In-kernel irqchips and >> device assignment are things that can live in qemu-kvm without much >> conflicts until they are finally mergable. >> > Upstream kvm is kinda useless without in-kernel irqchips. Not if its code serves the rest of qemu-kvm without further patches (and merge conflicts). And we only need to sort out the execution loop and threading stuff to get there. Jan
Attachment:
signature.asc
Description: OpenPGP digital signature
