Peter Xu <pet...@redhat.com> writes:
> This patchset introduces the singleton interface for QOM.
>
> The singleton interface is as simple as "this class can only create one
> instance".
>
> We used to have similar demand when working on all kinds of vIOMMUs,
> because in most cases that I am aware of, vIOMMU must be a singleton as
> it's closely bound to the machine and also the root PCIe systems. We used
> to have a bunch of special code guarding those, for example, X86 has
> pc_machine_device_pre_plug_cb() just to detect when vIOMMU is created more
> than once.
>
> There is a similar demand raising recently (even if the problem existed
> over years) when we were looking at a migration bug, that part of it was
> involved with the current_migration global pointer being referenced
> anywhere, even after the migration object was finalize()ed. So far without
> singleton support, there's no way to reset the variable properly.
> Declaring migration object to be a singleton also just makes sense, e.g.,
> dynamically creating migration objects on the fly with QMP commands doesn't
> sound right..
>
> The idea behind is pretty simple: any object that can only be created once
> can now declare the TYPE_SINGLETON interface, then QOM facilities will make
> sure it won't be created more than once. For example, qom-list-properties,
> device-list-properties, etc., will be smart enough to not try to create
> temporary singleton objects now.
QOM design assumption: object_new() followed by object_unref() is always
possible and has no side effect.
QOM introspection relies on this. Your PATCH 1 makes non-class
properties of singletons invisible in introspection. Making something
with such properties a singleton would be a regression.
Anything that violates the design assumption must be delayed to a
suitable state transition. For devices (subtypes of TYPE_DEVICE), this
is ->realize(). For user-creatable objects (provide interface
TYPE_USER_CREATABLE), this is ->complete(). For anything else, it's
something else that probably doesn't even exist, yet. See "Problem 5:
QOM lacks a clear life cycle" in
Subject: Dynamic & heterogeneous machines, initial configuration: problems
Date: Wed, 31 Jan 2024 21:14:21 +0100
Message-ID: <87o7d1i7ky....@pond.sub.org>
https://lore.kernel.org/qemu-devel/87o7d1i7ky....@pond.sub.org/
> Meanwhile, we also guard device-add paths
> so that it'll fail properly if it's created more than once (and iff it's a
> TYPE_DEVICE first).
[...]
