From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [Qemu-devel] [PATCH 28/35] kvm: x86: Introduce kvmclock device to save/restore its state Date: Wed, 19 Jan 2011 11:43:23 -0600 Message-ID: <4D3722BB.5030407@linux.vnet.ibm.com> References: <4D35B6DD.1020005@linux.vnet.ibm.com> <4D35B963.7000605@siemens.com> <4D35BA22.7060602@linux.vnet.ibm.com> <4D35BD30.1060900@siemens.com> <4D35C1CE.10509@linux.vnet.ibm.com> <4D35C648.7050809@siemens.com> <4D35C92D.7030000@linux.vnet.ibm.com> <4D36B362.70202@redhat.com> <4D371732.5040901@linux.vnet.ibm.com> <20110119171918.GI5113@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Markus Armbruster , "kvm@vger.kernel.org" , Jan Kiszka , Glauber Costa , Marcelo Tosatti , "qemu-devel@nongnu.org" , Gerd Hoffmann , Avi Kivity To: "Daniel P. Berrange" Return-path: Received: from e36.co.us.ibm.com ([32.97.110.154]:53188 "EHLO e36.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753848Ab1ASRnc (ORCPT ); Wed, 19 Jan 2011 12:43:32 -0500 Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by e36.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p0JHcY3w022914 for ; Wed, 19 Jan 2011 10:38:34 -0700 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay05.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p0JHhTD0078422 for ; Wed, 19 Jan 2011 10:43:29 -0700 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p0JHhRtx032054 for ; Wed, 19 Jan 2011 10:43:29 -0700 In-Reply-To: <20110119171918.GI5113@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 01/19/2011 11:19 AM, Daniel P. Berrange wrote: > > In our past experiance though, *not* specifying attributes like > these has also been pretty bad from a forward compatibility > perspective too. We're kind of damned either way, so on balance > we decided we'd specify every attribute in qdev that's related > to unique identification of devices& their inter-relationships. > By strictly locking down the topology we were defining, we ought > to have a more stable ABI in face of future changes. I accept > this might not always work out, so we may have to adjust things > over time still. Predicting the future is hard :-) > There are two distinct things here: 1) creating exactly the same virtual machine (like for migration) given a newer version of QEMU 2) creating a reasonably similar virtual machine given a newer version of QEMU For (1), you cannot use -M pc. You should use things like bus=X,addr=Y much better is for QEMU to dump a device file and to just reuse that instead of guessing what you need. For (2), you cannot use bus=X,addr=Y because it makes assumptions about the PCI topology which may change in newer -M pc's. I think libvirt needs to treat this two scenarios differently to support forwards compatibility. Regards, Anthony Liguori > Daniel >