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. Haozhong
