On 9/23/2024 1:31 PM, Chao Gao wrote: > On Thu, Sep 19, 2024 at 09:44:36AM +0000, Shivank Garg wrote: > > Do you need a way for the userspace to enumerate supported flags? > If the flag is not supported, the VMM will get a -EINVAL during memfd creation. > The direction was to implement a fbind() syscall [1]. I am not sure if it has > changed. What are the benefits of this proposal compared to the fbind() syscall? > > I believe one limitation of this proposal is that the policy must be set during > the creation of the guest-memfd. i.e., the policy cannot be changed at runtime. > is it a practical problem? > > [1]: https://lore.kernel.org/kvm/ZOjpIL0SFH+E3Dj4@xxxxxxxxxx/ > As the folio allocation happen via guest_memfd, this was an interesting idea for us to implement. And the mempolicy can be contained in guest_memfd. For changing policy at runtime, IOCTL KVM_GUEST_MEMFD_BIND can be proposed. However, I don't seem to find the support on KVM/QEMU for changing the memory binding at runtime. The fbind approach may pose a challenge for storing the mempolicy. Using "private" data fields of struct file or struct inode, can conflict with other user of those structures. And some way to inform (a new flag perhaps) the subsystem about private data is required for fbind purpose. Thanks, Shivank
