Re: [Qemu-devel] [PATCH v2 00/16] Postcopy: Hugepage support

[Andrea Arcangeli <aarcange@redhat.com>]

Hello,

On Mon, Feb 13, 2017 at 08:11:06PM +0300, Alexey Perevalov wrote:
> Another one request.
> QEMU could use mem_path in hugefs with share key simultaneously
> (-object memory-backend-file,id=mem,size=${mem_size},mem-path=${mem_path},share=on) and vm
> in this case will start and will properly work (it will allocate memory
> with mmap), but in case of destination for postcopy live migration
> UFFDIO_COPY ioctl will fail for
> such region, in Arcangeli's git tree there is such prevent check
> (if (!vma_is_shmem(dst_vma) && dst_vma->vm_flags & VM_SHARED).
> Is it possible to handle such situation at qemu?

It'd be nice to lift this hugetlbfs !VM_SHARED restriction I agree, I
already asked Mike (CC'ed) why is there, because I'm afraid it's a
leftover from the anon version where VM_SHARED means a very different
thing but it was already lifted for shmem. share=on should already
work on top of tmpfs and also with THP on tmpfs enabled.

For hugetlbfs and shmem it should be generally more complicated to
cope with private mappings than shared ones, shared is just the native
form of the pseudofs without having to deal with private COWs aliases
so it's hard to imagine something going wrong for VM_SHARED if the
MAP_PRIVATE mapping already works fine. If it turns out to be
superflous the check may be just turned into
"vma_is_anonymous(dst_vma) && dst_vma->vm_flags & VM_SHARED".

Thanks,
Andrea