From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55179) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uz4EL-0005in-2m for qemu-devel@nongnu.org; Tue, 16 Jul 2013 08:19:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Uz4EI-0000S8-6Y for qemu-devel@nongnu.org; Tue, 16 Jul 2013 08:19:45 -0400 Received: from cantor2.suse.de ([195.135.220.15]:57829 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uz4EH-0000Qz-TR for qemu-devel@nongnu.org; Tue, 16 Jul 2013 08:19:42 -0400 Message-ID: <51E53A59.4020802@suse.de> Date: Tue, 16 Jul 2013 14:19:37 +0200 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= MIME-Version: 1.0 References: <1373895639-21476-1-git-send-email-afaerber@suse.de> <51E40AAA.2010500@redhat.com> <51E40FEC.3030001@suse.de> <51E4174E.40704@redhat.com> In-Reply-To: <51E4174E.40704@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 17:37, schrieb Paolo Bonzini: > 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 propaga= ting from >>>> there on. This series now implements {realize,unrealize}_children at >>>> DeviceState level instead and propagates realized changes along buss= es rather >>>> than child<> properties. >>> >>> You are right that realize must be done after the bus is realized (an= d >>> unrealize must be done before the bus). But I'm afraid this opens a = can >>> of worms. >>> >>>> On machine creation done, a depth-first search is done >>>> for devices from /machine, which are then expected to further propag= ate 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 vi= sit >>> of their children (in either the QOM tree or the bus tree). What avo= ids >>> 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. >=20 > Why not? And anyway, just replace /superio with /pcnet-isa and > /superio/i8254 with /pcnet-isa/pcnet, and you get the same scenario. >=20 > 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. :) >=20 >> Is this hypothetical or do we need to fix qemu.git? >=20 > It is hypothetical, PC is not QOMified yet. >=20 >> 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. A= nd >> 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 it= s >> 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. >=20 > 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. >=20 > 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. >=20 >> Do you have a concrete example where we need such strict constraints? >=20 > Does there need to be a concrete example? My interest is this: Take a look at my tegra branch or PReP PCI or other composited SysBusDevices. Today I need to realize child devices in DeviceClass::realize, when I know that they should be realized through realize_children instead, outside of realize. So I don't want to convert all SysBusDevices to hand-code recursive realization (or at least the current version of it) and then go through and remove all that again in favor of realize_children. And since we are converting some devices for 1.6 I would like to have the work-saving solution for 1.6 as well. So it is not about /machine (2/3 is unused) but about the realize_children infrastructure (1/3). 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