From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: KVM call minutes for Mar 8 Date: Tue, 08 Mar 2011 17:51:03 +0100 Message-ID: <4D765E77.4020406@siemens.com> References: <20110308155024.GA10392@x200.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org, qemu-devel@nongnu.org To: Chris Wright Return-path: Received: from goliath.siemens.de ([192.35.17.28]:24081 "EHLO goliath.siemens.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754180Ab1CHQvU (ORCPT ); Tue, 8 Mar 2011 11:51:20 -0500 In-Reply-To: <20110308155024.GA10392@x200.localdomain> Sender: kvm-owner@vger.kernel.org List-ID: 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