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 12:58:06 -0600 Message-ID: <4D37343E.7050601@linux.vnet.ibm.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Gerd Hoffmann , Jan Kiszka , Avi Kivity , Markus Armbruster , Marcelo Tosatti , Glauber Costa , "kvm@vger.kernel.org" , "qemu-devel@nongnu.org" To: "Daniel P. Berrange" Return-path: Received: from e6.ny.us.ibm.com ([32.97.182.146]:33310 "EHLO e6.ny.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752255Ab1ASS6g (ORCPT ); Wed, 19 Jan 2011 13:58:36 -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 p0JIhwdN001527 for ; Wed, 19 Jan 2011 13:44:08 -0500 Received: from d01relay01.pok.ibm.com (d01relay01.pok.ibm.com [9.56.227.233]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id 904AF7280B6 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 d01relay01.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p0JIwCsO362636 for ; Wed, 19 Jan 2011 13:58:12 -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 p0JIwBDM001803 for ; Wed, 19 Jan 2011 16:58:12 -0200 In-Reply-To: <20110119185209.GL5113@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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 >