From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=56251 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PbI4K-0007EN-SQ for qemu-devel@nongnu.org; Fri, 07 Jan 2011 14:33:49 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PbI4I-0001Cv-4t for qemu-devel@nongnu.org; Fri, 07 Jan 2011 14:33:48 -0500 Received: from fmmailgate02.web.de ([217.72.192.227]:50233) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PbI4H-0001C2-Oj for qemu-devel@nongnu.org; Fri, 07 Jan 2011 14:33:46 -0500 Message-ID: <4D276A80.6000007@web.de> Date: Fri, 07 Jan 2011 20:33:20 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <4D2737EB.6070002@web.de> <20110107165359.GA10205@redhat.com> <4D274676.6000803@web.de> <20110107171653.GB10205@redhat.com> <4D274DD1.1020702@web.de> <20110107175307.GD10205@redhat.com> <4D275A40.9050106@web.de> <20110107191020.GE10205@redhat.com> In-Reply-To: <20110107191020.GE10205@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB43444DE281271FAB1196F7D" Sender: jan.kiszka@web.de Subject: [Qemu-devel] Re: qemu-kvm vs. qemu: Terminate cpu loop on reset? List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gleb Natapov Cc: qemu-devel , kvm This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB43444DE281271FAB1196F7D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 no= w, >>>> no more duplications with subtle differences, and production-grade k= vm >>>> upstream stability. >>>> >>> You are optimistic. My prediction is that it will take at least one m= ajor RHEL >>> release until such merged code base will become production-grade. Tha= t >>> is when most bugs that were introduced by eliminating subtle differen= ces >>> 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. >=20 >>> >>> 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 ste= ps. >> > I see only two threads on upstream no matter how much vcpus I configure= =2E /me sees a lot of them. Did you enable io-thread support? Otherwise kvm is run just like tcg in single-thread mode. >=20 >> 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 --------------enigB43444DE281271FAB1196F7D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk0naoAACgkQitSsb3rl5xS6IwCfW6Q9Fpatq6Sy1EnhUula+fjA 0OoAoK4rRTLINqNyuaA/Lslq79iV9uac =7aH7 -----END PGP SIGNATURE----- --------------enigB43444DE281271FAB1196F7D--