From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=44119 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PfdEs-0002pf-EM for qemu-devel@nongnu.org; Wed, 19 Jan 2011 13:58:39 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PfdEr-0002iN-8B for qemu-devel@nongnu.org; Wed, 19 Jan 2011 13:58:38 -0500 Received: from e6.ny.us.ibm.com ([32.97.182.146]:33307) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PfdEr-0002iD-0j for qemu-devel@nongnu.org; Wed, 19 Jan 2011 13:58:37 -0500 Received: from d01dlp01.pok.ibm.com (d01dlp01.pok.ibm.com [9.56.224.56]) by e6.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p0JIetv7027970 for ; Wed, 19 Jan 2011 13:44:08 -0500 Received: from d01relay05.pok.ibm.com (d01relay05.pok.ibm.com [9.56.227.237]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id 301627280A2 for ; Wed, 19 Jan 2011 13:58:12 -0500 (EST) Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p0JIwBjQ109118 for ; Wed, 19 Jan 2011 13:58:11 -0500 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p0JIwBDG001803 for ; Wed, 19 Jan 2011 16:58:11 -0200 Message-ID: <4D37343E.7050601@linux.vnet.ibm.com> Date: Wed, 19 Jan 2011 12:58:06 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 28/35] kvm: x86: Introduce kvmclock device to save/restore its state References: <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> <4D37170A.20205@linux.vnet.ibm.com> <20110119170144.GH5113@redhat.com> <4D3724BE.1030409@linux.vnet.ibm.com> <20110119185209.GL5113@redhat.com> In-Reply-To: <20110119185209.GL5113@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: "kvm@vger.kernel.org" , Jan Kiszka , Glauber Costa , Marcelo Tosatti , Markus Armbruster , "qemu-devel@nongnu.org" , Gerd Hoffmann , Avi Kivity On 01/19/2011 12:52 PM, Daniel P. Berrange wrote: > On Wed, Jan 19, 2011 at 11:51:58AM -0600, Anthony Liguori wrote: > >> On 01/19/2011 11:01 AM, Daniel P. Berrange wrote: >> >>> The reason we specify 'bus' is that we wanted to be flexible wrt >>> upgrades of libvirt, without needing restarts of QEMU instances >>> it manages. That way we can introduce new functionality into >>> libvirt that relies on it having previously set 'bus' on all >>> active QEMUs. >>> >>> If QEMU adds PCI-to-PCI bridges, then I wouldn't expect QEMU to >>> be adding the extra bridges. I'd expect that QEMU provided just >>> the first bridge and then libvirt would specify how many more >>> bridges to create at boot or hotplug them later. So it wouldn't >>> ever need to parse topology. >>> >> Yeah, but replacing the main chipset will certainly change the PCI >> topology such that if you're specifying bus=X and addr=X and then >> also using -M pc, unless you're parsing the default topology to come >> up with the addressing, it will break in the future. >> > We never use a bare '-M pc' though, we always canonicalize to > one of the versioned forms. So if we run '-M pc-0.12', then > neither the main PCI chipset nor topology would have changed > in newer QEMU. Of course if we deployed a new VM with > '-M pc-0.20' that might have new PCI chipset, so bus=pci.0 > might have different meaning that it did when used with > '-M pc-0.12', but I don't think that's an immediate problem > Right, but you expose bus addressing via the XML, no? That means that if a user specifies something like '1.0', and you translate that to bus='pci.0',addr='1.0', then when pc-0.50 comes out and slot 1.0 is used for the integrated 3D VGA graphics adapter, the guest creation will fail. If you expose topological configuration to the user, the guest will not continue working down the road unless you come up with a scheme where you map addresses to a different address range for newer pcs. Regards, Anthony Liguori > Regards, > Daniel >