Re: [PATCH v4 2/3] mac_via: fix incorrect creation of mos6522 device in mac_via

[Markus Armbruster <armbru@redhat.com>]

Paolo Bonzini <pbonzini@redhat.com> writes:

> On 16/03/20 07:03, Markus Armbruster wrote:
>> Paolo Bonzini <pbonzini@redhat.com> writes:
>> 
>>> On 15/03/20 15:56, Markus Armbruster wrote:
>>>>>
>>>>> The question is why they are not, i.e. where does the above reasoning break.
>>>> I don't know.  But let's for the sake of the argument assume this
>>>> actually worked.  Asking for help in the monitor then *still* has side
>>>> effects visible in the time span between .instance_init() and
>>>> finalization.
>>>>
>>>> Why is that harmless?
>>>
>>> I don't really have an answer, but if that is a problem we could change
>>> "info qtree" to skip non-realized devices.
>> 
>> Can we convince ourselves that "info qtree" is the *only* way to observe
>> these side effects?
>
> There is of course qom-get/qom-set, but those _should_ show this side
> effect.
>
> If we decide that "info qtree" should only show devices visible to the
> guest (as opposed to all objects that have been created), then "show
> only realized devices" is not even a hack but the correct implementation
> of the concept.
>
> Paolo
>
>> If yes, a hack to ignore unrealized devices "fixes" the problem.
>> 
>> If no, it sweeps it under the rug.

I fear we're getting lost in the weeds.  The question what qom-get /
qom-set / info qtree should show is of no concern to me when writing a
device model.  I need guidance on how to spread the work between
instance initialization and realize, and on the requirements for
unrealize and finalize.

Let's try to separate the self-evident parts from the unclear parts,
starting with the self-evident.  Please correct mistakes.

Object instantiation must be completely reverted by finalization.

device-introspect-test guards against a particularly egregious violation
of this rule, namely output of "info qtree" after initialization +
finalization differing from output before.  Surprisingly common issue.
It's what made Peter invite me to this thread.

Device realization must be completely reverted by unrealization.

We don't always implement unrealize.  Fine when the device cannot be
unrealized.  But the code doesn't seem to guard against omitting
unrealize when the device actually can be unrealized.

Properties for use with device_add must exist after object
instantiation.

But is that true?  Setting a property can run arbitrary code.  What if
setting property P to value V runs code that adds property Q?  Then
device_add P=V,Q=W works provided P gets set before Q, which is
anybody's guess.

So "must exist" is actually "should exist", and we' already moved from
the self-evident to the unclear.

Even less clear: what side effects may be visible between object
initialization and realization / finalization?

A safe but constricting answer would be "only host resource
reservation".

What's your answer?

I've hardly begun talking about the distribution of work between
initialization and realize, and I'm floundering already.  May I have
some clear, hard rules, please?