From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MAq5A-0005G5-Bq for qemu-devel@nongnu.org; Sun, 31 May 2009 14:48:32 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MAq55-0005FS-7T for qemu-devel@nongnu.org; Sun, 31 May 2009 14:48:31 -0400 Received: from [199.232.76.173] (port=43010 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MAq55-0005FP-1K for qemu-devel@nongnu.org; Sun, 31 May 2009 14:48:27 -0400 Received: from mail2.shareable.org ([80.68.89.115]:42976) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MAq54-0002t8-Jp for qemu-devel@nongnu.org; Sun, 31 May 2009 14:48:26 -0400 Date: Sun, 31 May 2009 19:48:20 +0100 From: Jamie Lokier Subject: Re: [Qemu-devel] [PATCH] Change virtio-console to PCI_CLASS_SERIAL_OTHER Message-ID: <20090531184820.GA31278@shareable.org> References: <1243012478.29542.18.camel@blaa> <4A1D4C57.6010109@us.ibm.com> <1243446153.4852.9.camel@blaa> <200905281353.50463.paul@codesourcery.com> <20090528130419.GC24488@redhat.com> <4A1E8F5D.1090408@us.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A1E8F5D.1090408@us.ibm.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Mark McLoughlin , Dor Laor , qemu-devel@nongnu.org, ajax@redhat.com, Paul Brook Anthony Liguori wrote: > The problem is that the device model a guest sees is an ABI. If we > change the ABI between versions, the guest make break. What I'm > proposing is that while we can change the default guest ABI between > versions, we must provide a way to recreate older forms of the guest ABI. > > A good example of guests breaking is Windows activation failing. It has > happened more than once that changes in QEMU cause Windows guests to > force reactivation. In more extreme instances, a guest may break that > used to work before. I agree. As far as I'm concerned, a major use of virtualisation is to be able to run old guests on newer hosts without having to keep changing the guest OS, including reinstalling its drivers etc. Because of this guest ABI compatibility is perhaps more important than it would be for othe rapplications. Windows activation is particularly ugly, but maybe we can special case that by making known relevant serial numbers, asset tags etc. configurable in the device model? You can avoid problems by sticking with a fixed QEMU/KVM version of course, but then you don't get the benefits of development like performance improvements and bug fixes. And in the long run, it doesn't work because older QEMU/KVMs don't work properly (or at all) on later host systems. If newer Qemu's can't do that, we'll eventually be in the curious position of having to use nested virtualisation - to run an older Qemu on an older nested 'host'. Sounds annoying :-) As soon as the device model config file is used, I expect all this will get easier to manage than it is now. The main thing then will be to ensure there are options to recreate old guest modes for particular devices. There's probably just a few such options, so not much of a maintenance burden. -- Jamie