From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=46225 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Px07p-0008UC-Ox for qemu-devel@nongnu.org; Tue, 08 Mar 2011 11:51:10 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Px07o-00007M-8T for qemu-devel@nongnu.org; Tue, 08 Mar 2011 11:51:09 -0500 Received: from goliath.siemens.de ([192.35.17.28]:18936) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Px07n-00006I-TB for qemu-devel@nongnu.org; Tue, 08 Mar 2011 11:51:08 -0500 Message-ID: <4D765E77.4020406@siemens.com> Date: Tue, 08 Mar 2011 17:51:03 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <20110308155024.GA10392@x200.localdomain> In-Reply-To: <20110308155024.GA10392@x200.localdomain> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: KVM call minutes for Mar 8 List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Chris Wright Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org On 2011-03-08 16:50, Chris Wright wrote: > iothread merge? > - progressing slowly, marcelo working on it > - have found regressions (signal handling code) (ifdef'd away for now) The regressions will automagically go away (to be replaced with others then...) when the switch of qemu-kvm to upstream bits is performed. They were related to qemu-kvm implementing iothread on top of non-threaded qemu and /me not looking careful enough on the implications. How this switch may look like can be seen here (slightly outdated version): http://git.kiszka.org/?p=qemu-kvm.git;a=shortlog;h=refs/heads/queues/qemu-kvm-merge git://git.kiszka.org/qemu-kvm.git queues/qemu-kvm-merge Part V of KVM upstream patches is under review ATM. I can post v2 if no one has further remarks. Then we could start with the review/merge work on qemu-kvm. The next time upstream will be involved again would be when preparing its device models and adding "-machine xxx,kvm-irqchip=..." for in-kernel irqchip support. That's more work, but it should not affect the execution model anymore. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux