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 > From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=37805 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PfcCW-00024L-TA for qemu-devel@nongnu.org; Wed, 19 Jan 2011 12:52:09 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PfcCU-00040k-DI for qemu-devel@nongnu.org; Wed, 19 Jan 2011 12:52:08 -0500 Received: from e36.co.us.ibm.com ([32.97.110.154]:54983) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PfcCU-00040N-5s for qemu-devel@nongnu.org; Wed, 19 Jan 2011 12:52:06 -0500 Received: from d03relay01.boulder.ibm.com (d03relay01.boulder.ibm.com [9.17.195.226]) by e36.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p0JHl9F4030554 for ; Wed, 19 Jan 2011 10:47:09 -0700 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay01.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p0JHq4ZO176688 for ; Wed, 19 Jan 2011 10:52:04 -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 p0JHq3Jc001027 for ; Wed, 19 Jan 2011 10:52:03 -0700 Message-ID: <4D3724BE.1030409@linux.vnet.ibm.com> Date: Wed, 19 Jan 2011 11:51:58 -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: <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> In-Reply-To: <20110119170144.GH5113@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 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 >