From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=37686 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pfrpu-0000OO-0H for qemu-devel@nongnu.org; Thu, 20 Jan 2011 05:33:51 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pfrps-0003mA-V5 for qemu-devel@nongnu.org; Thu, 20 Jan 2011 05:33:49 -0500 Received: from mx1.redhat.com ([209.132.183.28]:18201) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pfrps-0003m0-MZ for qemu-devel@nongnu.org; Thu, 20 Jan 2011 05:33:48 -0500 Date: Thu, 20 Jan 2011 10:33:41 +0000 From: "Daniel P. Berrange" Subject: Re: [Qemu-devel] [PATCH 28/35] kvm: x86: Introduce kvmclock device to save/restore its state Message-ID: <20110120103341.GA8675@redhat.com> References: <4D35BD30.1060900@siemens.com> <4D35C1CE.10509@linux.vnet.ibm.com> <4D35C648.7050809@siemens.com> <4D35C92D.7030000@linux.vnet.ibm.com> <4D36B362.70202@redhat.com> <4D371732.5040901@linux.vnet.ibm.com> <20110119171918.GI5113@redhat.com> <4D3722BB.5030407@linux.vnet.ibm.com> <4D37F5D5.3040409@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4D37F5D5.3040409@redhat.com> Reply-To: "Daniel P. Berrange" List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: "kvm@vger.kernel.org" , Jan Kiszka , Glauber Costa , Marcelo Tosatti , Markus Armbruster , "qemu-devel@nongnu.org" , Anthony Liguori , Avi Kivity On Thu, Jan 20, 2011 at 09:44:05AM +0100, Gerd Hoffmann wrote: > Hi, > > >For (2), you cannot use bus=X,addr=Y because it makes assumptions about > >the PCI topology which may change in newer -M pc's. > > Why should the PCI topology for 'pc' ever change? > > We'll probably get q35 support some day, but when this lands I > expect we'll see a new machine type 'q35', so '-m q35' will pick the > ich9 chipset (which will have a different pci topology of course) > and '-m pc' will pick the existing piix chipset (which will continue > to look like it looks today). If the topology does ever change (eg in the kind of way anthony suggests, first bus only has the graphics card), I think libvirt is going to need a little work to adapt to the new topology, regardless of whether we currently specify a bus= arg to -device or not. I'm not sure there's anything we could do to future proof us to that kind of change. Regards, Daniel