From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=41224 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PhI3J-00018j-Kh for qemu-devel@nongnu.org; Mon, 24 Jan 2011 03:45:35 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PhI3E-00040D-GF for qemu-devel@nongnu.org; Mon, 24 Jan 2011 03:45:33 -0500 Received: from mx1.redhat.com ([209.132.183.28]:28457) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PhI3E-0003yY-9F for qemu-devel@nongnu.org; Mon, 24 Jan 2011 03:45:28 -0500 Date: Mon, 24 Jan 2011 10:45:16 +0200 From: Gleb Natapov Subject: Re: [Qemu-devel] [PATCH 28/35] kvm: x86: Introduce kvmclock device to save/restore its state Message-ID: <20110124084516.GH28319@redhat.com> References: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D35C92D.7030000@linux.vnet.ibm.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: "kvm@vger.kernel.org" , Jan Kiszka , Glauber Costa , Marcelo Tosatti , Markus Armbruster , "qemu-devel@nongnu.org" , Avi Kivity On Tue, Jan 18, 2011 at 11:09:01AM -0600, Anthony Liguori wrote: > >>But we also need to provide a compatible interface to management tools. > >>Exposing the device model topology as a compatible interface > >>artificially limits us. It's far better to provide higher level > >>supported interfaces to give us the flexibility to change the device > >>model as we need to. > >How do you want to change qdev to keep the guest and management tool > >view stable while branching off kvm sub-buses? > > The qdev device model is not a stable interface. I think that's > been clear from the very beginning. > And what was the reason it was declared not stable? May be because we were not sure we will do it right from the start, so change will be needed later. But changes should bring qdev closer to reflect what guest expect device topology to look like. This will bring us to stable state as close possible. We need this knowledge and stability in qdev for device path creation. Both kind of device paths: OF and the one we use for migration. To create OF device path we need to know topology as seen by a guest (and guest does not care how isa bus is implemented internally inside south bridge), to create device path used for migration we need stability, otherwise change in qdev topology will break migration. All this artificial buses you propose to add move us in opposite direction and make qdev useless for anything but .... well for anything. -- Gleb.