From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [Qemu-devel] [PATCH 28/35] kvm: x86: Introduce kvmclock device to save/restore its state Date: Tue, 18 Jan 2011 11:31:19 -0600 Message-ID: <4D35CE67.3010902@linux.vnet.ibm.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Avi Kivity , Markus Armbruster , Marcelo Tosatti , Glauber Costa , "kvm@vger.kernel.org" , "qemu-devel@nongnu.org" To: Jan Kiszka Return-path: Received: from e31.co.us.ibm.com ([32.97.110.149]:32977 "EHLO e31.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752854Ab1ARRbc (ORCPT ); Tue, 18 Jan 2011 12:31:32 -0500 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e31.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p0IHHDFB007272 for ; Tue, 18 Jan 2011 10:17:13 -0700 Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p0IHVLmS047576 for ; Tue, 18 Jan 2011 10:31:22 -0700 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 p0IHZofR031431 for ; Tue, 18 Jan 2011 10:35:50 -0700 In-Reply-To: <4D35CBCE.3080900@siemens.com> Sender: kvm-owner@vger.kernel.org List-ID: 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 > >