On Fri, Jan 07, 2011 at 08:33:20PM +0100, Jan Kiszka wrote: > 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. > Upstream kvm was not "fork of the fork". It was something much worse then that. It was (bad) reimplementation of kvm that was unfortunately merged upstream. This slowed proper kvm inclusion into upstream for more then 2 years now (and counting). Glauber and you did (and do) a great job trying to sort this mess and nobody propose to throw what was done so far. qemu-kvm and qemu upstream uses a lot of common code. We can either try hard to consolidate even mode code, or at some point just merge qemu-kvm and drop upstream functions that are not used by qemu-kvm (ifdefed as obsolete in qemu-kvm tree). > 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. > I do not propose to drop bits from upstream that are used in qemu-kvm obviously. > > > >>> > >>> 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. > No, I didn't. Does io-thread work properly with TCG? IIRC there were problems with io thread + TCG. > > > >> 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. > This could have been achieved by not introducing upstream kvm in the first place :). Many if not most merging problems were result of rival kvm implementation in upstream. I thought the goal is to get rid of qemu-kvm fork at all by having fully functional kvm in upstream. -- Gleb. -- 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
