[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH RFC 0/3] Recursive QOM realize
From: |
Andreas Färber |
Subject: |
Re: [Qemu-devel] [PATCH RFC 0/3] Recursive QOM realize |
Date: |
Mon, 15 Jul 2013 17:06:20 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 |
Am 15.07.2013 16:43, schrieb Paolo Bonzini:
> Il 15/07/2013 15:40, Andreas Färber ha scritto:
>> Originally Paolo and me had implemented QOM realize at Object level.
>> Paolo's goal was to set realized = true on /machine and it propagating from
>> there on. This series now implements {realize,unrealize}_children at
>> DeviceState level instead and propagates realized changes along busses 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 can
> of worms.
>
>> On machine creation done, a depth-first search is done
>> for devices from /machine, which are then expected to further propagate 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 visit
> of their children (in either the QOM tree or the bus tree). What avoids
> 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
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg