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