Re: [RFC v2] memory.c: improve refcounting for RAM vs MMIO regions

[Peter Xu <peterx@redhat.com>]

On Tue, Aug 05, 2025 at 10:11:23AM +0200, Albert Esteve wrote:
> v1->v2:
> - Added documentation
> - Explained the reasoning in the commit message
> 
> In the last version of the SHMEM MAP/UNMAP [1] Stefan
> raised a concern [2] about dynamically creating and
> destroying memory regions and their lifecycle [3].
> 
> After some discussion, David Hildenbrand proposed
> to detect RAM regions and handle refcounting differently.
> I tried to extend the reasoning in the commit message
> below. If I wrote any innacuracies, please keep me
> honest. I hope we can gather some feedback with
> this RFC patch before sending it for inclusion.

This seems working.  Looks like so far all RAM MRs are fine with it, but
I'm not strongly confident it's true or it'll trivially keep true in the
future too.

Besides, this still adds some trivial complexity to memory_region_ref() on
treating RAM/MMIO MRs differently.

It also sounds like a pure "accident" that the shmem objects to be mapped
from the vhost-user devices are RAMs.  I wonder what happens if we want to
also support dynmaic MMIO regions.

Would this work even without changing QEMU memory core?

For example, have you thought about creating a VhostUserShmemObject for
each of the VHOST_USER_BACKEND_SHMEM_MAP request?

AFAICT, QEMU has complete refcounting support for objects, I thought that
should be totally fine being dynmaically created or destroyed.  Then MRs
will be children of those dynamic objects rather than the vhost-user
device.

Thanks,

-- 
Peter Xu