From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=42151 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PfFcw-0005b0-CW for qemu-devel@nongnu.org; Tue, 18 Jan 2011 12:46:17 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PfFci-0000fn-Bv for qemu-devel@nongnu.org; Tue, 18 Jan 2011 12:45:54 -0500 Received: from david.siemens.de ([192.35.17.14]:24250) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PfFci-0000do-2V for qemu-devel@nongnu.org; Tue, 18 Jan 2011 12:45:40 -0500 Message-ID: <4D35D1BF.80204@siemens.com> Date: Tue, 18 Jan 2011 18:45:35 +0100 From: Jan Kiszka 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> <4D35CE67.3010902@linux.vnet.ibm.com> In-Reply-To: <4D35CE67.3010902@linux.vnet.ibm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: "kvm@vger.kernel.org" , Glauber Costa , Marcelo Tosatti , "qemu-devel@nongnu.org" , Markus Armbruster , Avi Kivity On 2011-01-18 18:31, Anthony Liguori wrote: >>> 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. Unless we want to abuse the pointer property for this, and there was some resistance, we would have to change the sysbus init function signature. I don't want to propose this for a short-term workaround, we need a clearer vision and roadmap to avoid multiple invasive changes to the device model. > 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). The device model will always consist of a stable part, the guest and management visible topology. That beast needs to be modeled as well, likely via some new bus objects. If that's the way to go, starting now is probably the right time as we have an urgent use case, right? Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux