On 23.07.25 14:48, Albert Esteve wrote:
On Wed, Jul 23, 2025 at 2:43 PM David Hildenbrand <da...@redhat.com> wrote:
On 23.07.25 14:19, Albert Esteve wrote:
In the last version of the SHMEM MAP/UNMAP [1] there was a
comment [2] from Stefan about the lifecycle of the memory
regions.
After some discussion, David Hildenbrand proposed
to detect RAM regions and handle refcounting differently
to clear the initial concern. This RFC patch is
meant for gathering feedback from others
(i.e., Paolo Bonzini and Peter Xu).
[1] https://patchwork.ozlabs.org/project/qemu-devel/list/?series=460121
[2] https://patchwork.ozlabs.org/comment/3528600/
---
This patch enhances memory_region_ref() and memory_region_unref()
to handle RAM and MMIO memory regions differently, improving
reference counting semantics.
RAM regions now reference/unreference the memory region object
itself, while MMIO continue to reference/unreference the owner
device as before.
An additional qtest has been added to stress the memory
lifecycle. All tests pass as these changes keep backward
compatibility (prior behaviour is kept for MMIO regions).
Signed-off-by: David Hildenbrand <da...@redhat.com >
Signed-off-by: Albert Esteve <aest...@redhat.com>
---
system/memory.c | 22 +++++++++++++----
tests/qtest/ivshmem-test.c | 50 ++++++++++++++++++++++++++++++++++++++
2 files changed, 67 insertions(+), 5 deletions(-)
Did we discuss extending the doc as well, to clarify which scenario is
now supported?
Not that I remember? But it is a good idea. I will update the docs for
the next version of this patch.
Maybe I never sent it to you while brainstorming. Here is what I had:
diff --git a/docs/devel/memory.rst b/docs/devel/memory.rst
index 57fb2aec76..5c4bc9ced5 100644
--- a/docs/devel/memory.rst
+++ b/docs/devel/memory.rst
@@ -143,11 +143,13 @@ Region lifecycle
----------------
A region is created by one of the memory_region_init*() functions and
-attached to an object, which acts as its owner or parent. QEMU ensures
-that the owner object remains alive as long as the region is visible to
-the guest, or as long as the region is in use by a virtual CPU or another
-device. For example, the owner object will not die between an
-address_space_map operation and the corresponding address_space_unmap.
+attached to an object, which acts as its owner or parent.
+
+For non-RAM regions, QEMU ensures that the owner object remains alive as
+long as the region is visible to the guest, or as long as the region is in
+use by a virtual CPU or another device. For example, the owner object will
+not die between an address_space_map operation and the corresponding
+address_space_unmap. For RAM regions, this is not guaranteed.
After creation, a region can be added to an address space or a
container with memory_region_add_subregion(), and removed using
@@ -174,7 +176,8 @@ callback. The dynamically allocated data structure that
contains the
memory region then should obviously be freed in the instance_finalize
callback as well.
-If you break this rule, the following situation can happen:
+If you break this rule, the following situation can happen for non-RAM
+regions:
- the memory region's owner had a reference taken via memory_region_ref
(for example by address_space_map)
--
Cheers,
David / dhildenb
