On Wed, 17 Jun 2026, Mark Cave-Ayland wrote:
On 16/06/2026 16:55, Daniel P. Berrangé wrote:
QOM has two rather unusual / surprising features historicall
* The ability to embed a QOM instance's memory inside another
struct
* The ability to register properties against the instnce
instead of struct
While they both look convenient on the surface, they also
have significant undesirable side effects (see the commit
message for each patch for details).
The premise of this series is that their convenience does
not outweigh their downsides, and we would be better off
long term by eliminating their usage, rather than trying
to add more hacks on top to mitigate their downsides.
This comes out of two separate conversations this week
* Migration series where Peter proposed changes that
make use of instance properties. When I commented,
Peter rightly pointed out that our docs do not
discourage use of instance properties:
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.gnu.org_archive_html_qemu-2Ddevel_2026-2D06_msg02368.html&d=DwIDaQ&c=s883GpUCOChKOHiocYtGcg&r=c23RpsaH4D2MKyD3EPJTDa0BAxz6tV8aUJqVSoytEiY&m=VzbegkrZ5TGWl9jpxLUfD3gMp4ZZjyUrMiBfOzSjpcaOU-hz3SuUIaGUiIM4BQdV&s=v-N9FJZ1ugUjERquAp1KfuZ3B20G9mdbHpEEFP5zkfs&e=
* QOM series where Akihiko proposed some funky hacks
to reference counting to better track object lifecycle
when embedding structs. We had a short discussion about
discouraging QOM embedding, so this is a real world
proposal:
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.gnu.org_archive_html_qemu-2Ddevel_2026-2D06_msg03459.html&d=DwIDaQ&c=s883GpUCOChKOHiocYtGcg&r=c23RpsaH4D2MKyD3EPJTDa0BAxz6tV8aUJqVSoytEiY&m=VzbegkrZ5TGWl9jpxLUfD3gMp4ZZjyUrMiBfOzSjpcaOU-hz3SuUIaGUiIM4BQdV&s=mHTDgFeywt1U_2Q9uTnAyG6zp-VjguJ4DZIJAX59vaY&e=
This is not likely to be a quick task, so this series
starts small
* Adds a "QEMU_DEPRECATIONS" annotation for internal APIs
* Deprecate the QOM instance embedding
* Deprecate the QOM instance properties
* Deprecate the memory region embedding APIs
* Deprecate the IRQ embedding APIs
* Convert PIIX to eliminate embedding as a
demonstration.
The QEMU_DEPRECATIONS idea is an effect to improve our our
historic practice where we introduce a new preferred API
and never really tell anyone the old APIs is bad to use.
If --enable-deprecations is given to configure, every use
of a deprecated API emits a compiler warning. This is not
enabled by default in this series, since we have -Werror
by default.
I'm not sure if we're ready to start flagging things via the compiler,
however I'm in broad agreement that this is direction we need to travel.
Thanks for beating me to it, and starting the conversation :)
Note that the proposal to stop embedding memory regions has
been made by Zoltan earlier this year and was rejected by Paolo:
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.nongnu.org_archive_html_qemu-2Ddevel_2026-2D01_msg05435.html&d=DwIDaQ&c=s883GpUCOChKOHiocYtGcg&r=c23RpsaH4D2MKyD3EPJTDa0BAxz6tV8aUJqVSoytEiY&m=VzbegkrZ5TGWl9jpxLUfD3gMp4ZZjyUrMiBfOzSjpcaOU-hz3SuUIaGUiIM4BQdV&s=oAY3a1R4rnhYdl7-qnoTVjVdGOX1Qj-GvGlOX77oZrk&e=
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.nongnu.org_archive_html_qemu-2Ddevel_2026-2D05_msg06665.html&d=DwIDaQ&c=s883GpUCOChKOHiocYtGcg&r=c23RpsaH4D2MKyD3EPJTDa0BAxz6tV8aUJqVSoytEiY&m=VzbegkrZ5TGWl9jpxLUfD3gMp4ZZjyUrMiBfOzSjpcaOU-hz3SuUIaGUiIM4BQdV&s=WmpukrnrmuhhTz7hLgAA-9FStZ3fbzH3P1aT_U9f6GY&e=
I don't really agree with the analysis there. IMHO, the
concept of embedding objects is to horrendous to allow to
live any longer. Yes, that's a big job, but long term it
is worth it.
FWIW my main objection to the series was that it added yet another way of
doing something to fix a particular issue in legacy code. I have a suspicion
that if we can make everything in QOM properly refcounted then this approach
could work globally: in particular I can see it would fix issues where the
flatviews hold references to memory regions outside of the device lifecycle
until the RCU thread tidies up.
However as you can see, there would be quite a bit of work to get there. But
at least if we can all agree on the way forward, we can start to get the
relevant changes in place.
We can't convert the whole code base at once and it's unrealistic to
expect a single contributor like me to do that to accept my patch. What I
proposed is a start that can be used now for the cases I have and can
serve as a basis for future conversions. I did not propose to convert
everything either because I think having both ref counted and externally
managed memory regions can be useful in different cases and I don't see
having two ways for this confusing considering we have object_new and
object_initialize for same reasons. But if we deprecate object_initialize
then the memory_region_init functions are not needed either.
Originally I also thought about splitting alloc and init similar to how
macOS Foundation does it (i.e. [[obj alloc] init]) so the allocation of
the memory region could be done by either object_new or embedded but that
does not work due to object_new setting free function and
object_initialize clearing it so you can only use either one or the other.
Therefore since memory_region_init calls object_initialize we need a
memory_region_new variant that uses object_new instead or we end up
having to convert the whole code base again to decouple object
initialization from memory_region_init so I did not go that way.
Regards,
BALATON Zoltan
