From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:36055) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RuqNY-00074y-Ul for qemu-devel@nongnu.org; Tue, 07 Feb 2012 14:07:02 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RuqNX-00074z-6r for qemu-devel@nongnu.org; Tue, 07 Feb 2012 14:07:00 -0500 Received: from mail-pz0-f45.google.com ([209.85.210.45]:53607) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RuqNW-00074p-W9 for qemu-devel@nongnu.org; Tue, 07 Feb 2012 14:06:59 -0500 Received: by dadp14 with SMTP id p14so7892616dad.4 for ; Tue, 07 Feb 2012 11:06:57 -0800 (PST) Message-ID: <4F31764D.2090302@codemonkey.ws> Date: Tue, 07 Feb 2012 13:06:53 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <87ehu7pxvf.fsf@elfo.elfo> <4F312AFC.6020908@suse.de> <4F3166EC.7000002@codemonkey.ws> <4F316AB8.1060207@suse.de> In-Reply-To: <4F316AB8.1060207@suse.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] KVM call agenda for Tuesday 7 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?ISO-8859-15?Q?Andreas_F=E4rber?= Cc: Developers qemu-devel , KVM devel mailing list , quintela@redhat.com On 02/07/2012 12:17 PM, Andreas Färber wrote: > Am 07.02.2012 19:01, schrieb Anthony Liguori: >> On 02/07/2012 07:45 AM, Andreas Färber wrote: >>> http://lists.gnu.org/archive/html/qemu-devel/2012-01/msg04065.html >>> >>> How is the realize step (DeviceState::init) supposed to translate to >>> Object-derived classes (e.g., CPU) and where to draw the line between >>> initfn and realize. >> >> Realize probably should be folded into Object or some intermediate object. >> >> The idea is that there will be a realized boolean property. When the >> level changes, it will invoke a realize() or unrealize() method >> depending on the direction. DeviceState will implement realize() and >> invoke init(). For unrealize(), it will invoke exit(). > > That's fine. Question is, who is in charge of setting the realized > property Ideally, the user, but there is a lot of refactoring to get there. Realize should propagate through the composition tree (in such a way that it can be overridden, of course). > and some rules of what do we put in initfn and what in realize. instance_init: - initialize fields that don't depend on properties - install properties - initialize children realize: - validate all properties have sane values - perform initialization that depends on properties - take any actions that would logically "start" the device - propagate to children unrealize: - take any actions that would logically "stop" the device - propagate to children - restore fields to the values after reset finalize: - take any actions that would logically "stop" the device - free any sources of the device What we think of reset today is unrealize(). What with thing of as qdev_init is instance_init + realize. One thing I'd like to do is make the default implementation of unrealize() essentially be finalize + reinit in the same memory location. This would make it so that the vast majority of devices would not need to implement reset. > Take the CPU, should CPU reset be done in realize or initfn? Forget about reset as you know it. initfn should initialize state. Realize should only deal with starting the VM. > realize > might overwrite values set by the user after initfn but would provide us > with a reproducible state wrt reboot. > > Starting the VCPU thread would definitely be for realize, but currently > this is all done from cpu_*_init() and having sequential calls to initfn > and realize doesn't offer any advantage over doing it all in initfn. In general, if something can be done in initfn, it should be done there. > So given we do the split, who knows about these objects to call their > realize function? '/' is an object (it's a container). It will have a realize property that it propagates to all of it's children. So a user simply has to set /.realize = true and that will realize the entire graph of objects. > Will there be some global QOM logic that calls realize > on all objects instantiated so far (any ordering constraints then?) or > is everyone themselves responsible for making this work, i.e. must I > keep a global list of all CPUs initfn'ed to have their realize method > called later? Nope, it all will just magically work. Regards, Anthony Liguori > > Andreas >