From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [Qemu-devel] KVM call agenda for Tuesday 7 Date: Tue, 07 Feb 2012 13:06:53 -0600 Message-ID: <4F31764D.2090302@codemonkey.ws> References: <87ehu7pxvf.fsf@elfo.elfo> <4F312AFC.6020908@suse.de> <4F3166EC.7000002@codemonkey.ws> <4F316AB8.1060207@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Developers qemu-devel , KVM devel mailing list , quintela@redhat.com To: =?ISO-8859-15?Q?Andreas_F=E4rber?= Return-path: Received: from mail-pw0-f46.google.com ([209.85.160.46]:39030 "EHLO mail-pw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754671Ab2BGTG6 (ORCPT ); Tue, 7 Feb 2012 14:06:58 -0500 Received: by pbcun15 with SMTP id un15so81224pbc.19 for ; Tue, 07 Feb 2012 11:06:57 -0800 (PST) In-Reply-To: <4F316AB8.1060207@suse.de> Sender: kvm-owner@vger.kernel.org List-ID: On 02/07/2012 12:17 PM, Andreas F=E4rber wrote: > Am 07.02.2012 19:01, schrieb Anthony Liguori: >> On 02/07/2012 07:45 AM, Andreas F=E4rber wrote: >>> http://lists.gnu.org/archive/html/qemu-devel/2012-01/msg04065.html >>> >>> How is the realize step (DeviceState::init) supposed to translate t= o >>> Object-derived classes (e.g., CPU) and where to draw the line betwe= en >>> initfn and realize. >> >> Realize probably should be folded into Object or some intermediate o= bject. >> >> The idea is that there will be a realized boolean property. When th= e >> level changes, it will invoke a realize() or unrealize() method >> depending on the direction. DeviceState will implement realize() an= d >> 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 th= at it can=20 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 qde= v_init is=20 instance_init + realize. One thing I'd like to do is make the default implementation of unrealiz= e()=20 essentially be finalize + reinit in the same memory location. This wou= ld make=20 it so that the vast majority of devices would not need to implement res= et. > Take the CPU, should CPU reset be done in realize or initfn? =46orget about reset as you know it. initfn should initialize state. = Realize=20 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 current= ly > this is all done from cpu_*_init() and having sequential calls to ini= tfn > 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= =2E > 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 t= hat it=20 propagates to all of it's children. So a user simply has to set /.realize =3D true and that will realize th= e entire=20 graph of objects. > Will there be some global QOM logic that calls realize > on all objects instantiated so far (any ordering constraints then?) o= r > 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 >