> > On 02/07/18 19:52 +0800, Haozhong Zhang wrote: > > On 02/07/18 11:38 +0000, Dr. David Alan Gilbert wrote: > > > * Haozhong Zhang (haozhong.zh...@intel.com) wrote: > > > > When loading a zero page, check whether it will be loaded to > > > > persistent memory If yes, load it by libpmem function > > > > pmem_memset_nodrain(). Combined with a call to pmem_drain() at the > > > > end of RAM loading, we can guarantee all those zero pages are > > > > persistently loaded. > > > > > > I'm surprised pmem is this invasive to be honest; I hadn't expected > > > the need for special memcpy's etc everywhere. We're bound to miss some. > > > I assume there's separate kernel work needed to make postcopy work; > > > certainly the patches here don't seem to touch the postcopy path. > > > > This link at > > https://wiki.qemu.org/Features/PostCopyLiveMigration#Conflicts shows > > that postcopy with memory-backend-file requires kernel support. Can > > you point me the details of the required kernel support, so that I can > > understand what would be needed to NVDIMM postcopy? > > I saw test_ramblock_postcopiable() requires the ram block not be > mmap'ed with MAP_SHARED. The only pmem device (i.e., device DAX e.g., > /dev/dax0.0) that can be safely used as the backend of vNVDIMM must be > shared mapped which is required by kernel, so postcopy does not work > with pmem right now. Even if the private mmap was supported for device > dax, it would still make little sense to private mmap it in QEMU, > because vNVDIMM intends to be non-volatile.
o.k that's the reason post-copy pages does not work with THP. If we want to support device DAX with postcopy we need to handle this use-case? Adding 'Andrea' to the thread for more clear answer. Thanks, Pankaj
