From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38350) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UykM5-0008M6-9f for qemu-devel@nongnu.org; Mon, 15 Jul 2013 11:06:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UykM3-0007dg-8T for qemu-devel@nongnu.org; Mon, 15 Jul 2013 11:06:25 -0400 Received: from cantor2.suse.de ([195.135.220.15]:45585 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UykM2-0007dA-W1 for qemu-devel@nongnu.org; Mon, 15 Jul 2013 11:06:23 -0400 Message-ID: <51E40FEC.3030001@suse.de> Date: Mon, 15 Jul 2013 17:06:20 +0200 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= MIME-Version: 1.0 References: <1373895639-21476-1-git-send-email-afaerber@suse.de> <51E40AAA.2010500@redhat.com> In-Reply-To: <51E40AAA.2010500@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH RFC 0/3] Recursive QOM realize List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Blue Swirl , Hu Tao , "Peter C. Crosthwaite" , qemu-devel@nongnu.org, Anthony Liguori Am 15.07.2013 16:43, schrieb Paolo Bonzini: > Il 15/07/2013 15:40, Andreas F=C3=A4rber ha scritto: >> Originally Paolo and me had implemented QOM realize at Object level. >> Paolo's goal was to set realized =3D true on /machine and it propagati= ng from >> there on. This series now implements {realize,unrealize}_children at >> DeviceState level instead and propagates realized changes along busses= rather >> than child<> properties. >=20 > You are right that realize must be done after the bus is realized (and > unrealize must be done before the bus). But I'm afraid this opens a ca= n > of worms. >=20 >> On machine creation done, a depth-first search is done >> for devices from /machine, which are then expected to further propagat= e the >> property change. >=20 > How do you ensure that devices are realized before their bus's parent > _and_ before their parent? With two constraints for each device, we > have a graph, not anymore a tree. Example: >=20 >=20 > (1) this is the composition tree >=20 > /machine > ,------' | '------. > /pci-host /isa /superio > ,----' '----. > /i8254 /i8259 >=20 >=20 > (2) this is the bus tree >=20 > PCI (/pci-host) > | > ISA (/isa) > ,-----------' '------. > /superio/i8254 /superio/i8259 >=20 >=20 > The constraints are: >=20 > - pci-host before isa > - superio before superio/i8254 > - superio before superio/i8259 > - isa before superio/i8254 > - isa before superio/i8259 >=20 > So the two valid orders are >=20 > - /machine, pci-host, superio, isa, superio/i8254, superio/8259 > - /machine, pci-host, isa, superio, superio/i8254, superio/8259 >=20 > You cannot say whether superio or isa are encountered first, so you > cannot say whether it is superio or isa that should "hold off" the visi= t > of their children (in either the QOM tree or the bus tree). What avoid= s > us having to do a full topological ordering of the graph? I would say your example is wrong. :) There should be no /machine/isa node. Is this hypothetical or do we need to fix qemu.git? There will be a /machine/sysbus node though, which may lead to similar ordering uncertainties. However SysBusDevices don't usually have a hosting device today, so I don't think it's a problem at the moment. And not for busses either since they are no devices. If we have a /machine/superio that would be a SysBusDevice (in PReP it would be a PCIDevice and thus not directly on /machine), we would need to walk its children to their bus and its parent device and assure it is realized before - I think there's still sufficient time until 1.6 to get something minimal sorted out. Do you have a concrete example where we need such strict constraints? Andreas --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=C3=B6rffer; HRB 16746 AG N=C3=BC= rnberg