From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=51099 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Pfd8n-0007RO-IM
	for qemu-devel@nongnu.org; Wed, 19 Jan 2011 13:52:24 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <berrange@redhat.com>) id 1Pfd8k-0001AF-C6
	for qemu-devel@nongnu.org; Wed, 19 Jan 2011 13:52:21 -0500
Received: from mx1.redhat.com ([209.132.183.28]:36568)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <berrange@redhat.com>) id 1Pfd8k-00019r-3Q
	for qemu-devel@nongnu.org; Wed, 19 Jan 2011 13:52:18 -0500
Date: Wed, 19 Jan 2011 18:52:09 +0000
From: "Daniel P. Berrange" <berrange@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 28/35] kvm: x86: Introduce kvmclock device
	to save/restore its state
Message-ID: <20110119185209.GL5113@redhat.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>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <4D3724BE.1030409@linux.vnet.ibm.com>
Reply-To: "Daniel P. Berrange" <berrange@redhat.com>
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Anthony Liguori <aliguori@linux.vnet.ibm.com>
Cc: "kvm@vger.kernel.org" <kvm@vger.kernel.org>, Jan Kiszka <jan.kiszka@siemens.com>, Glauber Costa <glommer@redhat.com>, Marcelo Tosatti <mtosatti@redhat.com>, Markus Armbruster <armbru@redhat.com>, "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>, Gerd Hoffmann <kraxel@redhat.com>, Avi Kivity <avi@redhat.com>

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

Regards,
Daniel