From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M9nR3-0003Yl-9e for qemu-devel@nongnu.org; Thu, 28 May 2009 17:46:49 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M9nQy-0003V3-JL for qemu-devel@nongnu.org; Thu, 28 May 2009 17:46:48 -0400 Received: from [199.232.76.173] (port=32864 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M9nQy-0003Ue-6m for qemu-devel@nongnu.org; Thu, 28 May 2009 17:46:44 -0400 Received: from mx2.redhat.com ([66.187.237.31]:57259) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1M9nQx-0000NI-Lm for qemu-devel@nongnu.org; Thu, 28 May 2009 17:46:43 -0400 Message-ID: <4A1F05DE.6060806@redhat.com> Date: Fri, 29 May 2009 00:45:02 +0300 From: Dor Laor MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] Change virtio-console to PCI_CLASS_SERIAL_OTHER References: <1243012478.29542.18.camel@blaa> <200905281353.50463.paul@codesourcery.com> <4A1E8A16.3060101@us.ibm.com> <200905281422.52420.paul@codesourcery.com> <4A1E91AF.9050907@us.ibm.com> In-Reply-To: <4A1E91AF.9050907@us.ibm.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Reply-To: dlaor@redhat.com List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Mark McLoughlin , ajax@redhat.com, Paul Brook , qemu-devel@nongnu.org Anthony Liguori wrote: > Paul Brook wrote: > >>>>> - 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. >>>> >>>> >>> It is very worth the pain. I consider it a core requirement. >>> >>> >> We disagree then. You're effectively requiring bug-compatibility. >> >> > > You can take it to an extreme and require bug-compatibility, but I don't > think that's necessary. I think there's room for being reasonable. > > >> This may be reasonable for a stable branch, but is not something I have any >> interest in across different release cycles. IMHO major VM upgrades should be >> considered the same as real hardware or firmware upgrades. >> >> > > I think major VM upgrades is something that can be considered > occasionally but every 6 months would be pretty painful to most users. > I think we ought to make a best effort to maintain compatibility with > older versions as long as it's reasonable. > > Supporting live migration between different versions of qemu is a stretch goal. In the past 2 month we fixed about 10 basic live migration issues and mainline keeps breaking ;( Nevertheless, as Anthony states, guest ABI should be rock stable. We should have mechanism (machine conf format++) that will enable us to configure pci addresses, cpuid entries, memory layout, device existence (hpet, virtio-console,..), etc. Anyhow, I did sent a patch to allow virtio block to parametrized class value - http://lists.gnu.org/archive/html/qemu-devel/2009-05/msg01189.html There wasn't a perfect match with finding the right interface to change it, happy to hear other alternatives if you're not happy with it. Thanks, Dor > Regards, > > Anthony Liguori > > >> Paul >> >> > > > >