On Thu, Aug 7, 2025 at 9:22 AM Albert Esteve <aest...@redhat.com> wrote: > > On Wed, Aug 6, 2025 at 10:36 PM David Hildenbrand <da...@redhat.com> wrote: > > > > On 06.08.25 22:15, Peter Xu wrote: > > > 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. > > > > Is this use case realistic? > > > > If there is a reasonable way to prepare for such hypothetical use cases > > them while solving Albert's immediate use case, I'm all for it. > > > > > > > > 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? > > > > You mean, adding an intermediate object that remains the parent of these > > MemoryRegion? > > > > Could work. To free a MemoryRegion, I guess we would unparent that > > intermediate object, and that object would then free the memory region > > -- unless something still references that intermediate object. Not sure > > if the memory region might keep the intermediate object still alive (no > > idea). > > > > Certainly something to explore, Albert, can you look into that? > > Sure, I will try this. Thank you both for the time and help.
I did test this approach with a rust-vmm modified backend and the buffer were created/destroyed correctly. I just posted the version 6 of the SHMEM_MAP/UNMAP patch. So unless there are other issues with the other patch series implementation, I think we can discard this RFC. Either way, thanks for the feedback and suggestions! > > > > > -- > > Cheers, > > > > David / dhildenb > >
