From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52530) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ejQQv-0000TE-AE for qemu-devel@nongnu.org; Wed, 07 Feb 2018 09:10:50 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ejQQs-0002Ju-UY for qemu-devel@nongnu.org; Wed, 07 Feb 2018 09:10:45 -0500 Received: from mx1.redhat.com ([209.132.183.28]:54192) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ejQQs-0002Jf-Oo for qemu-devel@nongnu.org; Wed, 07 Feb 2018 09:10:42 -0500 Date: Wed, 7 Feb 2018 09:10:40 -0500 (EST) From: Pankaj Gupta Message-ID: <323806882.1237280.1518012640808.JavaMail.zimbra@redhat.com> In-Reply-To: <20180207125141.cajtcvlsatwplfxh@hz-desktop> References: <20180207073331.14158-1-haozhong.zhang@intel.com> <20180207073331.14158-6-haozhong.zhang@intel.com> <20180207113841.GB2665@work-vm> <20180207115207.qeqld4v3hl246qu4@hz-desktop> <20180207125141.cajtcvlsatwplfxh@hz-desktop> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2 5/8] migration/ram: ensure write persistence on loading zero pages to PMEM List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Haozhong Zhang , Andrea Arcangeli Cc: "Dr. David Alan Gilbert" , qemu-devel@nongnu.org, Eduardo Habkost , Igor Mammedov , Paolo Bonzini , mst@redhat.com, Xiao Guangrong , Juan Quintela , Stefan Hajnoczi , Dan Williams > > 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.zhang@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