From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gerd Hoffmann Subject: Re: [Qemu-devel] [PATCH 28/35] kvm: x86: Introduce kvmclock device to save/restore its state Date: Fri, 21 Jan 2011 09:35:06 +0100 Message-ID: <4D39453A.6090609@redhat.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "Daniel P. Berrange" , Markus Armbruster , "kvm@vger.kernel.org" , Jan Kiszka , Glauber Costa , Marcelo Tosatti , "qemu-devel@nongnu.org" , Avi Kivity To: Anthony Liguori Return-path: Received: from mx1.redhat.com ([209.132.183.28]:35260 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753203Ab1AUIfX (ORCPT ); Fri, 21 Jan 2011 03:35:23 -0500 In-Reply-To: <4D388F60.5070001@linux.vnet.ibm.com> Sender: kvm-owner@vger.kernel.org List-ID: 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. cheers, Gerd