Re: [PATCH 0/5] KVM: guest_memfd: bind backing memory to a NUMA node

["David Hildenbrand (Arm)" <david@kernel.org>]

On 9/10/26 15:39, Gregory Price wrote:
> On Thu, Sep 10, 2026 at 01:32:08PM +0200, David Hildenbrand (Arm) wrote:
>>>
>>> the eventual intent is to enable this for fully confidential,
>>> host-unmapped guest, isolated to a particular memory device.
>>>
>>> Requiring a mapping to get node-placement is quite defeating the point.
>>
>> You only need a VMA, not actually mapped/faulted pages. So I don't immediately
>> see the problem?
>>
> 
> There is no VMA here - only an inode (GMEM_I), which is where the
> shared policy hangs off of.
> 
> So yeah, if there was a vma, that's i suppose the missing component
> needed to hook up userland mempolicy to all of this - but I would have
> thought creating a VMA for guest_memfd is hacky and confusing (since its
> intent is to basically not have a VMA).

The VMA is irrelevant, you just don't want to fault in the pages. In fact, you'd
only need the VMA while setting the policy. (similar to shmem)

> 
> Is there a series I missed that was proposing this?
I recall that we definitely discussed this in on of our meetings, but I don't
remember whether we decided to not fully support this case given that in-place
conversation is on the horizon.

I think you can open a private-only guest_memfd with GUEST_MEMFD_FLAG_MMAP, and
it will reject to fault-in any pages, but GUEST_MEMFD_FLAG_MMAP also changes the
way memory pages are obtained:

"When the KVM MMU performs a PFN lookup to service a guest fault and the backing
guest_memfd has the GUEST_MEMFD_FLAG_MMAP set, then the fault will always be
consumed from guest_memfd, regardless of whether it is a shared or a private fault".

For shared-only that makes perfect sense. For private-only, where shared memory
pages would come from a user VMA, this wouldn't really work.

But I don't know how your case would look like (where are shared pages? are
there any ever?)

-- 
Cheers,

David