On Mon, 15 Jun 2026, Mark Cave-Ayland wrote:
But embedded MemoryRegions are enormously common, and devices
that embed other devices that embed MemoryRegions are also
pretty common. So I don't know how much of a gradual approach
you could take for the issue descibed in this patch.
Zoltan did post a patch that allowed for adding externally referenced
MemoryRegions a while back: my reason for not supporting the approach was
because it added yet another way of adding MemoryRegions to work around a
particular legacy use case. However if there is agreement that this is the
way we should do things, I suspect that the series will have solved most of
the problems in this area.
That series was blocked by Paolo saying no:
https://lists.nongnu.org/archive/html/qemu-devel/2026-05/msg06665.html
without ever explaining why it should not be allowed to create ref counted
memory regions. even though it's documented and implemented that way
already, but the current memory_region_init() functions don't allow using
that and forces every memory region to either be embedded or leaked. I
still think that using QOM to manage memory region life time with ref
counts is useful as it also makes device models simpler and my series
allows incremental conversion as it only adds the functions to create QOM
managed memory regions leaving the exising embedded regions untouched so
they could be converted one by one when needed. If there's more interest
in this now I can update and repost it again or I'd still like to see an
explanation why it is not wanted.
Regards,
BALATON Zoltan
