From mboxrd@z Thu Jan 1 00:00:00 1970 From: Markus Armbruster Subject: Re: [Qemu-devel] [PATCH 28/35] kvm: x86: Introduce kvmclock device to save/restore its state Date: Fri, 21 Jan 2011 11:03:40 +0100 Message-ID: References: <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> <4D371732.5040901@linux.vnet.ibm.com> <20110119171918.GI5113@redhat.com> <4D3722BB.5030407@linux.vnet.ibm.com> <4D37F5D5.3040409@redhat.com> <4D388F60.5070001@linux.vnet.ibm.com> <4D39453A.6090609@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Anthony Liguori , "kvm\@vger.kernel.org" , Jan Kiszka , Glauber Costa , Marcelo Tosatti , "qemu-devel\@nongnu.org" , Avi Kivity To: Gerd Hoffmann Return-path: Received: from mx1.redhat.com ([209.132.183.28]:59335 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753091Ab1AUKEN (ORCPT ); Fri, 21 Jan 2011 05:04:13 -0500 In-Reply-To: <4D39453A.6090609@redhat.com> (Gerd Hoffmann's message of "Fri, 21 Jan 2011 09:35:06 +0100") Sender: kvm-owner@vger.kernel.org List-ID: Gerd Hoffmann writes: > On 01/20/11 20:39, Anthony Liguori wrote: >> On 01/20/2011 02:44 AM, 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). >> >> But then what's the default machine type? When I say -M pc, I really >> mean the default machine. > > I'd tend to leave pc as default for a release cycle or two so we can > hash out issues with q35, then flip the default once it got broader > testing and runs stable. > >> At some point, "qemu-system-x86_64 -device virtio-net-pci,addr=2.0" >> >> Is not going to be a reliable way to invoke qemu because there's no way >> we can guarantee that slot 2 isn't occupied by a chipset device or some >> other default device. > > Indeed. But qemu -M pc should continue to work though. 'pc' would > better named 'piix3', but renaming it now is probably not worth the > trouble. We mustn't change pc-0.14 & friends. We routinely change pc, but whether an upgrade to q35 qualifies as routine change is debatable. If you don't want PCI topology (and more) to change across QEMU updates, consider using the versioned machine types. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=33254 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PgDr6-0007GO-2E for qemu-devel@nongnu.org; Fri, 21 Jan 2011 05:04:53 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PgDqm-0007H2-1p for qemu-devel@nongnu.org; Fri, 21 Jan 2011 05:04:32 -0500 Received: from mx1.redhat.com ([209.132.183.28]:59478) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PgDql-0007Gf-R7 for qemu-devel@nongnu.org; Fri, 21 Jan 2011 05:04:12 -0500 From: Markus Armbruster Subject: Re: [Qemu-devel] [PATCH 28/35] kvm: x86: Introduce kvmclock device to save/restore its state References: <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> <4D371732.5040901@linux.vnet.ibm.com> <20110119171918.GI5113@redhat.com> <4D3722BB.5030407@linux.vnet.ibm.com> <4D37F5D5.3040409@redhat.com> <4D388F60.5070001@linux.vnet.ibm.com> <4D39453A.6090609@redhat.com> Date: Fri, 21 Jan 2011 11:03:40 +0100 In-Reply-To: <4D39453A.6090609@redhat.com> (Gerd Hoffmann's message of "Fri, 21 Jan 2011 09:35:06 +0100") Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 , "qemu-devel@nongnu.org" , Anthony Liguori , Avi Kivity Gerd Hoffmann writes: > On 01/20/11 20:39, Anthony Liguori wrote: >> On 01/20/2011 02:44 AM, 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). >> >> But then what's the default machine type? When I say -M pc, I really >> mean the default machine. > > I'd tend to leave pc as default for a release cycle or two so we can > hash out issues with q35, then flip the default once it got broader > testing and runs stable. > >> At some point, "qemu-system-x86_64 -device virtio-net-pci,addr=2.0" >> >> Is not going to be a reliable way to invoke qemu because there's no way >> we can guarantee that slot 2 isn't occupied by a chipset device or some >> other default device. > > Indeed. But qemu -M pc should continue to work though. 'pc' would > better named 'piix3', but renaming it now is probably not worth the > trouble. We mustn't change pc-0.14 & friends. We routinely change pc, but whether an upgrade to q35 qualifies as routine change is debatable. If you don't want PCI topology (and more) to change across QEMU updates, consider using the versioned machine types.