From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M9f7Q-0007Kp-Tv for qemu-devel@nongnu.org; Thu, 28 May 2009 08:54:00 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M9f7M-00074J-5U for qemu-devel@nongnu.org; Thu, 28 May 2009 08:54:00 -0400 Received: from [199.232.76.173] (port=42475 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M9f7L-00073y-UZ for qemu-devel@nongnu.org; Thu, 28 May 2009 08:53:55 -0400 Received: from mx20.gnu.org ([199.232.41.8]:29078) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1M9f7L-0001dn-JC for qemu-devel@nongnu.org; Thu, 28 May 2009 08:53:55 -0400 Received: from mail.codesourcery.com ([65.74.133.4]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1M9f7J-000499-Lr for qemu-devel@nongnu.org; Thu, 28 May 2009 08:53:54 -0400 From: Paul Brook Subject: Re: [Qemu-devel] [PATCH] Change virtio-console to PCI_CLASS_SERIAL_OTHER Date: Thu, 28 May 2009 13:53:49 +0100 References: <1243012478.29542.18.camel@blaa> <4A1D4C57.6010109@us.ibm.com> <1243446153.4852.9.camel@blaa> In-Reply-To: <1243446153.4852.9.camel@blaa> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905281353.50463.paul@codesourcery.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org, Mark McLoughlin Cc: Anthony Liguori , Dor Laor , ajax@redhat.com On Wednesday 27 May 2009, Mark McLoughlin wrote: > On Wed, 2009-05-27 at 09:21 -0500, Anthony Liguori wrote: > > We need a mechanism to toggle this for both this and virtio-blk. The > > reason a toggle is needed is so that 0.11 can create the same device > > model as 0.10. > > Okay, so the scenario is: > > - 0.10 guest running on source machine > > - migrate to dest machine running 0.11 > > - the device model cannot change or the guest OS will get confused IMHO think the only sane response is "don't do that". Trying to support migration between different qemu versions just isn't worth the pain. Paul