qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Stefan Hajnoczi <stefanha@gmail.com>
To: Albert Esteve <aesteve@redhat.com>
Cc: "Philippe Mathieu-Daudé" <philmd@linaro.org>,
	qemu-devel@nongnu.org, stefanha@redhat.com,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"David Hildenbrand" <david@redhat.com>,
	peterx@redhat.com, "Laurent Vivier" <lvivier@redhat.com>,
	"Fabiano Rosas" <farosas@suse.de>,
	"Markus Armbruster" <armbru@redhat.com>
Subject: Re: [RFC] memory.c: improve refcounting for RAM vs MMIO regions
Date: Wed, 23 Jul 2025 10:59:12 -0400	[thread overview]
Message-ID: <CAJSP0QWqRij-dfsBCv9YRCJ_toDG6446ciVxbFDEytbQ_6iFrw@mail.gmail.com> (raw)
In-Reply-To: <CADSE00Lp0W_nsUqqTz7=JmyzLuJjMdOq8WkFXeBAtOxe-yDCPg@mail.gmail.com>

On Wed, Jul 23, 2025 at 8:44 AM Albert Esteve <aesteve@redhat.com> wrote:
>
> On Wed, Jul 23, 2025 at 2:32 PM Philippe Mathieu-Daudé
> <philmd@linaro.org> wrote:
> >
> > Hi,
> >
> > On 23/7/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 <david@redhat.com >
> > > Signed-off-by: Albert Esteve <aesteve@redhat.com>
> > > ---
> > >   system/memory.c            | 22 +++++++++++++----
> > >   tests/qtest/ivshmem-test.c | 50 ++++++++++++++++++++++++++++++++++++++
> > >   2 files changed, 67 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/system/memory.c b/system/memory.c
> > > index 5646547940..48ab6e5592 100644
> > > --- a/system/memory.c
> > > +++ b/system/memory.c
> > > @@ -1826,6 +1826,14 @@ Object *memory_region_owner(MemoryRegion *mr)
> > >
> > >   void memory_region_ref(MemoryRegion *mr)
> > >   {
> > > +    /* Regions without an owner are considered static. */
> > > +    if (!mr || !mr->owner) {
> > > +        return;
> > > +    }
> > > +    if (mr->ram) {
> > > +        object_ref(OBJECT(mr));
> > > +        return;
> > > +    }
> > >       /* MMIO callbacks most likely will access data that belongs
> > >        * to the owner, hence the need to ref/unref the owner whenever
> > >        * the memory region is in use.
> > > @@ -1836,16 +1844,20 @@ void memory_region_ref(MemoryRegion *mr)
> > >        * Memory regions without an owner are supposed to never go away;
> >
> > What are the use cases for MRs without QOM owner?
>
> Not sure if you are asking about the logic or the actual usecases
> where these MRs would make sense.
>
> Regarding the logic, note the early return at the beginning of the
> function, so that this comment is kept valid. In short, nothing
> changes.
>
> Regarding the usecases for these type of memories, I can think of
> system memory or container regions as examples. But there are
> certainly more experienced people in this thread that can answer you
> better than me.

I had similar thoughts to Phil when reading the commit description. It
says what the patch is doing but does not really describe why.

Please update the commit description to state why RAM regions need
different refcount semantics.

Stefan


  parent reply	other threads:[~2025-07-23 15:01 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-23 12:19 [RFC] memory.c: improve refcounting for RAM vs MMIO regions Albert Esteve
2025-07-23 12:32 ` Philippe Mathieu-Daudé
2025-07-23 12:42   ` Albert Esteve
2025-07-23 12:45     ` David Hildenbrand
2025-07-23 12:53       ` David Hildenbrand
2025-07-23 14:59     ` Stefan Hajnoczi [this message]
2025-07-23 12:43 ` David Hildenbrand
2025-07-23 12:48   ` Albert Esteve
2025-07-23 12:54     ` David Hildenbrand

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAJSP0QWqRij-dfsBCv9YRCJ_toDG6446ciVxbFDEytbQ_6iFrw@mail.gmail.com \
    --to=stefanha@gmail.com \
    --cc=aesteve@redhat.com \
    --cc=armbru@redhat.com \
    --cc=david@redhat.com \
    --cc=farosas@suse.de \
    --cc=lvivier@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peterx@redhat.com \
    --cc=philmd@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).