From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MwIe3-0007mM-1i for qemu-devel@nongnu.org; Fri, 09 Oct 2009 12:48:43 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MwIdy-0007gl-8I for qemu-devel@nongnu.org; Fri, 09 Oct 2009 12:48:42 -0400 Received: from [199.232.76.173] (port=56603 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MwIdx-0007gG-LD for qemu-devel@nongnu.org; Fri, 09 Oct 2009 12:48:37 -0400 Received: from mail2.shareable.org ([80.68.89.115]:42866) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MwIdx-0007xq-8Y for qemu-devel@nongnu.org; Fri, 09 Oct 2009 12:48:37 -0400 Date: Fri, 9 Oct 2009 17:48:31 +0100 From: Jamie Lokier Subject: Re: [Qemu-devel] Re: [PATCH v2 4/9] provide in-kernel apic Message-ID: <20091009164831.GB7393@shareable.org> References: <1254953315-5761-1-git-send-email-glommer@redhat.com> <1254953315-5761-2-git-send-email-glommer@redhat.com> <1254953315-5761-3-git-send-email-glommer@redhat.com> <1254953315-5761-4-git-send-email-glommer@redhat.com> <1254953315-5761-5-git-send-email-glommer@redhat.com> <4ACDEF42.6020706@us.ibm.com> <4ACDF297.9010303@redhat.com> <20091008142202.GR8092@mothafucka.localdomain> <20091009100641.GC6576@shareable.org> <20091009143031.GU8092@mothafucka.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091009143031.GU8092@mothafucka.localdomain> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Glauber Costa Cc: Anthony Liguori , Avi Kivity , kvm-devel , qemu-devel@nongnu.org Glauber Costa wrote: > On Fri, Oct 09, 2009 at 11:06:41AM +0100, Jamie Lokier wrote: > > Glauber Costa wrote: > > > > It ensures the two models are compatible. Since they're the same device > > > > from the point of view of the guest, there's no reason for them to have > > > > different representations or to be incompatible. > > > > > > live migration between something that has in-kernel irqchip and > > > something that has not is likely to be a completely untested > > > thing. And this is the only reason we might think of it as the same > > > device. I don't see any value in supporting this combination > > > > Not just live migration. ACPI sleep + savevm + loadvm + ACPI resume, > > for example. > Yes, but in this case too, I'd expect the irqchipness of qemu not to change. If I've just been sent an image produced by someone running KVM, and my machine is not KVM-capable, or I cannot upgrade the KVM kernel module because it's in use by other VMs (had this problem a few times), there's no choice but to change the irqchipness. -- Jamie