From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MsRAe-00053Q-DU for qemu-devel@nongnu.org; Mon, 28 Sep 2009 21:06:24 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MsRAZ-00051Q-Iu for qemu-devel@nongnu.org; Mon, 28 Sep 2009 21:06:23 -0400 Received: from [199.232.76.173] (port=54002 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MsRAZ-00051L-Em for qemu-devel@nongnu.org; Mon, 28 Sep 2009 21:06:19 -0400 Received: from mx1.redhat.com ([209.132.183.28]:5155) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MsRAZ-00036R-1M for qemu-devel@nongnu.org; Mon, 28 Sep 2009 21:06:19 -0400 Date: Mon, 28 Sep 2009 22:06:15 -0300 From: Glauber Costa Subject: Re: [Qemu-devel] [PATCH 0/6] in kernel irqchip support Message-ID: <20090929010614.GS29735@mothafucka.localdomain> References: <1254172517-28216-1-git-send-email-glommer@redhat.com> <20090929003958.GA5527@shareable.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090929003958.GA5527@shareable.org> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jamie Lokier Cc: aliguori@us.ibm.com, qemu-devel@nongnu.org On Tue, Sep 29, 2009 at 01:39:58AM +0100, Jamie Lokier wrote: > Glauber Costa wrote: > >I am ready to advocate that it should be the default, whenever > >available. I plan to, however, provide a patch that disables it > >whenever this gets merged. > > Is the in-kernel irqchip simply intended to accelerate some part of > the CPU/irq emulation, so that you could enable or disable it at will, > as well as migrating to TCG-using systems and back, with no observable > effect except performance? I don't think we can migrate between kvm and tcg. Although it should be possible in theory, since we just load the state, there are some differences, specially with respect to memory layout between kvm and pure tcg. i.e., IIRC, kvm puts two extra pages in the end of the registered physical memory. Although it can be possible, I don't think anyone has enough interest to make it happen. As for in-kernel chip, to be honest, I have never tried migrating between two system, one having it, and one lacking it. But I believe it should be possible, and this is a much easier goal to accomplish.