From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=41992 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PfFW2-0007Fc-U4 for qemu-devel@nongnu.org; Tue, 18 Jan 2011 12:39:17 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PfFV1-0006On-HY for qemu-devel@nongnu.org; Tue, 18 Jan 2011 12:38:29 -0500 Received: from e6.ny.us.ibm.com ([32.97.182.146]:51048) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PfFV1-0006Of-Eg for qemu-devel@nongnu.org; Tue, 18 Jan 2011 12:37:43 -0500 Received: from d01dlp01.pok.ibm.com (d01dlp01.pok.ibm.com [9.56.224.56]) by e6.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p0IHLY8w028159 for ; Tue, 18 Jan 2011 12:23:13 -0500 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id 1CA52728C0B for ; Tue, 18 Jan 2011 12:31:22 -0500 (EST) Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p0IHVL8f148260 for ; Tue, 18 Jan 2011 12:31:21 -0500 Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p0IHZofL031431 for ; Tue, 18 Jan 2011 10:35:50 -0700 Message-ID: <4D35CE67.3010902@linux.vnet.ibm.com> Date: Tue, 18 Jan 2011 11:31:19 -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: <4D2B6CB5.9050602@codemonkey.ws> <4D2B74D8.4080309@web.de> <4D2B8662.9060909@web.de> <4D2C60FB.7030009@linux.vnet.ibm.com> <4D2D80ED.8030405@redhat.com> <4D2D82EE.20002@siemens.com> <4D35A39A.8000801@siemens.com> <4D35ABF8.9050700@linux.vnet.ibm.com> <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> <4D35CBCE.3080900@siemens.com> In-Reply-To: <4D35CBCE.3080900@siemens.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: "kvm@vger.kernel.org" , Glauber Costa , Marcelo Tosatti , "qemu-devel@nongnu.org" , Markus Armbruster , Avi Kivity On 01/18/2011 11:20 AM, Jan Kiszka wrote: > > Which only works as along as we expose a single bus. You don't need to > be an oracle to predict that this is not a stable interface. > Today we only have a very low level factory interface--device creation and deletion. I think we should move to higher level bus factory interfaces. An interface to create a PCI device and to delete PCI devices. This is the only sane way to do hot plug. This also makes supporting multiple busses a lot more reasonable since this factory interface could be a method of the controller. >> It's automatically created as part of the CPUs or as part of the >> chipset. How to enable/disable kvm assistance is a property of the CPU >> and/or chipset. >> > If we exclude creation via command line / config files, we could also > pass the kvm_state directly from the machine or chipset setup code and > save us at least the kvm system buses. > Which is fine in the short term. This is exactly why we don't want the device model to be an ABI. It gives us the ability to make changes as they make sense instead of trying to be perfect from the start (which we never will be). Regards, Anthony Liguori > Jan > >