On Fri, 8 Mar 2024 15:22:50 -0800, Sean Christopherson wrote: > On Fri, Mar 08, 2024, James Gowans wrote: > > We are also aware of ongoing work on guest_memfd. The current > > implementation unmaps guest memory from VMM address space, but leaves it > > in the kernel’s direct map. We’re not looking at unmapping from VMM > > userspace yet; we still need guest RAM there for PV drivers like virtio > > to continue to work. So KVM’s gmem doesn’t seem like the right solution? > > We (and by "we", I really mean the pKVM folks) are also working on allowing > userspace to mmap() guest_memfd[*]. pKVM aside, the long term vision I have > for > guest_memfd is to be able to use it for non-CoCo VMs, precisely for the > security > and robustness benefits it can bring. > > What I am hoping to do with guest_memfd is get userspace to only map memory it > needs, e.g. for emulated/synthetic devices, on-demand. I.e. to get to a state > where guest memory is mapped only when it needs to be.
Thank you for the direction, this is super helpful. We are new to the guest_memfd space, and for simplicity we'd prefer to leave guest_memfd completely mapped in userspace. Even in the long term, we actually don't have any use for unmapping from host userspace. The current form of marking pages shared doesn't quite align with what we're trying to do either since it also shares the pages with the host kernel. What are your thoughts on a flag for KVM_CREATE_GUEST_MEMFD that only removes from the host kernel's direct map, but leaves everything mapped in userspace? Derek
