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:51:58 -0600 Message-ID: <4D3724BE.1030409@linux.vnet.ibm.com> References: <4D35B521.3090601@siemens.com> <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> <4D37170A.20205@linux.vnet.ibm.com> <20110119170144.GH5113@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 e33.co.us.ibm.com ([32.97.110.151]:39450 "EHLO e33.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753267Ab1ASRwI (ORCPT ); Wed, 19 Jan 2011 12:52:08 -0500 Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by e33.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p0JHjxqR032075 for ; Wed, 19 Jan 2011 10:45:59 -0700 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay05.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p0JHq5rJ015866 for ; Wed, 19 Jan 2011 10:52:05 -0700 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p0JHq3Ji001027 for ; Wed, 19 Jan 2011 10:52:04 -0700 In-Reply-To: <20110119170144.GH5113@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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. That's why I think something simpler like a linear index that QEMU maps to a static location in the topology is probably the best future proof interface. Regards, Anthony Liguori > Regards, > Daniel >