From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M9yeW-0002Ee-EZ for qemu-devel@nongnu.org; Fri, 29 May 2009 05:45:28 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M9yeS-0002Ag-0Q for qemu-devel@nongnu.org; Fri, 29 May 2009 05:45:27 -0400 Received: from [199.232.76.173] (port=53836 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M9yeR-0002AA-GZ for qemu-devel@nongnu.org; Fri, 29 May 2009 05:45:23 -0400 Received: from mx20.gnu.org ([199.232.41.8]:56303) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1M9yeQ-0008Io-W7 for qemu-devel@nongnu.org; Fri, 29 May 2009 05:45:23 -0400 Received: from mx2.redhat.com ([66.187.237.31]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1M9yeP-0003Oc-LE for qemu-devel@nongnu.org; Fri, 29 May 2009 05:45:21 -0400 Subject: Re: [Qemu-devel] [PATCH] Change virtio-console to PCI_CLASS_SERIAL_OTHER From: Mark McLoughlin In-Reply-To: <4A1F05DE.6060806@redhat.com> 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> <4A1F05DE.6060806@redhat.com> Content-Type: text/plain Date: Fri, 29 May 2009 10:43:13 +0100 Message-Id: <1243590193.13990.73.camel@blaa> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Reply-To: Mark McLoughlin List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dlaor@redhat.com Cc: Anthony Liguori , ajax@redhat.com, Paul Brook , qemu-devel@nongnu.org On Fri, 2009-05-29 at 00:45 +0300, Dor Laor wrote: > 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. As I said, it's pointless to add something like this if, realistically, it will never be used. So, taking the example of '-drive class=foo' ... a user who runs qemu directly would have to know that when she updates from qemu-0.10.x to qemu-0.11.x, she needs to use '-drive class=384' for ever more. I find it hard to believe anyone will ever do that. Perhaps management tools can hide this complexity? In order to do this in libvirt, we'd need to do the following: 1) Add a 'pci_class' property to : 2) If a guest's configuration does not contain the pci_class property, then once the guest is running, parse the output of 'info pci', somehow map each disk to a PCI address, map the class descriptions to class numbers and save the class to the guests configuration. 3) If a given qemu binary supports '-drive class=', then pass it the class value on startup, if configured 4) Require users to update to libvirt and run the guest at least once with the old version of qemu, before updating to the new version of qemu Assuming this is actually possible to implement (see "somehow" in step 2), I doubt anyone would ever be bothered enough to implement it. Anthony's suggestion of a way to list device properties would help a little in theory, but in practice the old qemu binary wouldn't have this command so libvirt would have no way of finding this class=384 value. A machine configuration format (even assuming a command to dump the configuration of a guest) doesn't help much more, for the same reason. And none of this solves the problem that management tools have to play catch up - they cannot predict how we will change the ABI, so users have to update to a newer version of the management tools with code to support the ABI change *before* updating qemu. The more I think about it, no matter how much linear ABI versioning sucks, it's possibly the only way to solve this in a reasonably usable manners. Distros would just have to suck it up and agree that if they cherry-pick an ABI changing patch, they must update the entire ABI to the newer upstream ABI version. Cheers, Mark.