Re: [PATCH 4/8] memory: Rename RAM_GUEST_MEMFD to RAM_GUEST_MEMFD_PRIVATE

[Xiaoyao Li <xiaoyao.li@intel.com>]

On 11/14/2025 5:25 AM, Peter Xu wrote:
> On Fri, Oct 24, 2025 at 05:17:20PM +0800, Xiaoyao Li wrote:
>> On 10/24/2025 2:59 AM, Peter Xu wrote:
>>> This name is too generic, and can conflict with in-place guest-memfd
>>> support.  Add a _PRIVATE suffix to show what it really means: it is always
>>> silently using an internal guest-memfd to back a shared host backend,
>>> rather than used in-place.
>>>
>>> This paves way for in-place guest-memfd, which means we can have a ramblock
>>> that allocates pages completely from guest-memfd (private or shared).
>>
>> It's for patch 4-7. Regarding the rename. How about:
>>
>> - RAM_GUEST_MEMFD => RAM_PRIVATE_MEMORY
>> - backend->guest_memfd => backend->private_memory
>> - machine_require_guest_memfd() => machine_require_private_memory()
>> - cgs->require_guest_memfd => cgs->require_private_memory
>>
>> For CoCo VMs, what they require is the support of private memory, while the
>> guest_memfd is how linux provides private memory support. But with mmap
>> support added to guest memfd, it can serve as shared/non-private memory as
>> well. Futher, in the future when in-place conversion support is implemented,
>> a single guest memfd can serve as both shared and private in different
>> parts. So guest_memfd_private will be confusing at that time.
> 
> That's more or less a valid point.
> 
> Said so, I think PRIVATE_MEMORY is confusing too v.s. RAM_PRIVATE.  See:
> 
> commit 6169f1193657d0ba630a2ce33cef639ae918bce4
> Author: Steve Sistare <steven.sistare@oracle.com>
> Date:   Wed Jan 15 11:00:31 2025 -0800
> 
>      memory: add RAM_PRIVATE
> 
> Not to mention its possible confusion against mmap(MAP_PRIVATE) which is
> even more well known (where here RAM_PRIVATE is exactly about it).
> 
> It'll not be a concern until private gmemfd will start to back shared
> memories, even if it happens (I believe it will, a matter of time..) IMHO
> it's still fine to use guest_memfd_private, because here private describes
> that the fd is a private FD (not the memory is private).  It's private
> because it's hidden inside each ramblock that matters.  Then a fd that is
> private can still back shared memories.
> 
> Would you mind I keep everything as-is for now?

I'm fine.

> Thanks,
>