Re: [Qemu-devel] [PATCH RFC 0/3] Recursive QOM realize

[Paolo Bonzini <pbonzini@redhat.com>]

Il 15/07/2013 17:06, Andreas Färber ha scritto:
> 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.

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. 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.

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