From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48856) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uykqn-0006tr-0V for qemu-devel@nongnu.org; Mon, 15 Jul 2013 11:38:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Uykql-0000pn-4n for qemu-devel@nongnu.org; Mon, 15 Jul 2013 11:38:08 -0400 Received: from mx1.redhat.com ([209.132.183.28]:46739) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uykqk-0000p3-T0 for qemu-devel@nongnu.org; Mon, 15 Jul 2013 11:38:07 -0400 Message-ID: <51E4174E.40704@redhat.com> Date: Mon, 15 Jul 2013 17:37:50 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1373895639-21476-1-git-send-email-afaerber@suse.de> <51E40AAA.2010500@redhat.com> <51E40FEC.3030001@suse.de> In-Reply-To: <51E40FEC.3030001@suse.de> 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: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= Cc: Blue Swirl , Hu Tao , "Peter C. Crosthwaite" , qemu-devel@nongnu.org, Anthony Liguori Il 15/07/2013 17:06, Andreas F=C3=A4rber ha scritto: > 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 propagat= ing from >>> there on. This series now implements {realize,unrealize}_children at >>> DeviceState level instead and propagates realized changes along busse= s rather >>> than child<> properties. >> >> 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 c= an >> of worms. >> >>> On machine creation done, a depth-first search is done >>> for devices from /machine, which are then expected to further propaga= te the >>> property change. >> >> 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: >> >> >> (1) this is the composition tree >> >> /machine >> ,------' | '------. >> /pci-host /isa /superio >> ,----' '----. >> /i8254 /i8259 >> >> >> (2) this is the bus tree >> >> PCI (/pci-host) >> | >> ISA (/isa) >> ,-----------' '------. >> /superio/i8254 /superio/i8259 >> >> >> The constraints are: >> >> - pci-host before isa >> - superio before superio/i8254 >> - superio before superio/i8259 >> - isa before superio/i8254 >> - isa before superio/i8259 >> >> So the two valid orders are >> >> - /machine, pci-host, superio, isa, superio/i8254, superio/8259 >> - /machine, pci-host, isa, superio, superio/i8254, superio/8259 >> >> 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 vis= it >> of their children (in either the QOM tree or the bus tree). What avoi= ds >> us having to do a full topological ordering of the graph? >=20 > I would say your example is wrong. :) There should be no /machine/isa > node. Why not? And anyway, just replace /superio with /pcnet-isa and /superio/i8254 with /pcnet-isa/pcnet, and you get the same scenario. Perhaps you could say my example is wrong, because one of the two constraints should not be there. If you have a good argument for that, I can buy it. :) > Is this hypothetical or do we need to fix qemu.git? It is hypothetical, PC is not QOMified yet. > 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. An= d > 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. I don't think this is 1.6 material, and there is no need to start with something minimal. Let's focus on getting things right. Perhaps "right" means that only one of the two trees need to be visited. That's what I did in my old prototype, but I'm fairly convinced it was wrong. > Do you have a concrete example where we need such strict constraints? Does there need to be a concrete example? Paolo