Re: [RFC PATCH 0/4] KVM: ioctl for populating guest_memfd

[Nikita Kalyazin <kalyazin@amazon.com>]

On 20/11/2024 13:55, Paolo Bonzini wrote:
>> Patch 4 allows to call the ioctl from a separate (non-VMM) process.  It
>> has been prohibited by [3], but I have not been able to locate the exact
>> justification for the requirement.
> 
> The justification is that the "struct kvm" has a long-lived tie to a
> host process's address space.
> 
> Invoking ioctls like KVM_SET_USER_MEMORY_REGION and KVM_RUN from
> different processes would make things very messy, because it is not
> clear which mm you are working with: the MMU notifier is registered for
> kvm->mm, but some functions such as get_user_pages do not take an mm for
> example and always operate on current->mm.

That's fair, thanks for the explanation.

> In your case, it should be enough to add a ioctl on the guestmemfd
> instead?

That's right. That would be sufficient indeed.  Is that something that 
could be considered?  Would that be some non-KVM API, with guest_memfd 
moving to an mm library?

 > But the real question is, what are you using
 > KVM_X86_SW_PROTECTED_VM for?

The concrete use case is VM restoration from a snapshot in Firecracker 
[1].  In the current setup, the VMM registers a UFFD against the guest 
memory and sends the UFFD handle to an external process that knows how 
to obtain the snapshotted memory.  We would like to preserve the 
semantics, but also remove the guest memory from the direct map [2]. 
Mimicing this with guest_memfd would be sending some form of a 
guest_memfd handle to that process that would be using it to populate 
guest_memfd.

[1]: 
https://github.com/firecracker-microvm/firecracker/blob/main/docs/snapshotting/handling-page-faults-on-snapshot-resume.md#userfaultfd
[2]: 
https://lore.kernel.org/kvm/20241030134912.515725-1-roypat@amazon.co.uk/T/

> Paolo