Re: [PATCH v12 08/18] KVM: guest_memfd: Allow host to map guest_memfd pages

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

On 6/18/2025 4:15 PM, David Hildenbrand wrote:
>> If we are really dead set on having SHARED in the name, it could be
>> GUEST_MEMFD_FLAG_USER_MAPPABLE_SHARED or 
>> GUEST_MEMFD_FLAG_USER_MAP_SHARED?  But
>> to me that's _too_ specific and again somewhat confusing given the 
>> unfortunate
>> private vs. shared usage in CoCo-land.  And just playing the odds, I'm 
>> fine taking
>> a risk of ending up with GUEST_MEMFD_FLAG_USER_MAPPABLE_PRIVATE or 
>> whatever,
>> because I think that is comically unlikely to happen.
> 
> I think in addition to GUEST_MEMFD_FLAG_MMAP we want something to 
> express "this is not your old guest_memfd that only supports private 
> memory". And that's what I am struggling with.

Sorry for chiming in.

Per my understanding, (old) guest memfd only means it's the memory that 
cannot be accessed by userspace. There should be no shared/private 
concept on it.

And "private" is the concept of KVM. Guest memfd can serve as private 
memory, is just due to the character of it cannot be accessed from 
userspace.

So if the guest memfd can be mmap'ed, then it become userspace 
accessable and cannot serve as private memory.

> Now, if you argue "support for mmap() implies support for non-private 
> memory", I'm probably okay for that.

I would say, support for mmap() implies cannot be used as private memory.

> I could envision support for non-private memory even without mmap() 
> support, how useful that might be, I don't know. But that's why I was 
> arguing that we mmap() is just one way to consume non-private memory.