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
