From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Tian, Kevin" <kevin.tian@intel.com>
Subject: Re: [RFC Design Doc] Add vNVDIMM support for Xen
Date: Tue, 2 Feb 2016 08:03:13 +0000
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D15F7941D4@SHSMSX101.ccr.corp.intel.com>
References: <20160201054414.GA25211@hz-desktop.sh.intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D15F793F7D@SHSMSX101.ccr.corp.intel.com>
	<20160202073901.GI6293@hz-desktop.sh.intel.com>
	<AADFC41AFE54684AB9EE6CBC0274A5D15F794131@SHSMSX101.ccr.corp.intel.com>
	<20160202075316.GJ6293@hz-desktop.sh.intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <20160202075316.GJ6293@hz-desktop.sh.intel.com>
Content-Language: en-US
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: "Zhang, Haozhong" <haozhong.zhang@intel.com>
Cc: Juergen Gross <jgross@suse.com>, Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>, George Dunlap <George.Dunlap@eu.citrix.com>, Andrew Cooper <andrew.cooper3@citrix.com>, Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Ian Jackson <ian.jackson@eu.citrix.com>, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, Jan Beulich <jbeulich@suse.com>, "Nakajima, Jun" <jun.nakajima@intel.com>, Xiao Guangrong <guangrong.xiao@linux.intel.com>, Keir Fraser <keir@xen.org>
List-Id: xen-devel@lists.xenproject.org

> From: Zhang, Haozhong
> Sent: Tuesday, February 02, 2016 3:53 PM
> 
> On 02/02/16 15:48, Tian, Kevin wrote:
> > > From: Zhang, Haozhong
> > > Sent: Tuesday, February 02, 2016 3:39 PM
> > >
> > > > btw, how is persistency guaranteed in KVM/QEMU, cross guest
> > > > power off/on? I guess since Qemu process is killed the allocated pmem
> > > > will be freed so you may switch to file-backed method to keep
> > > > persistency (however copy would take time for large pmem trunk). Or
> > > > will you find some way to keep pmem managed separated from qemu
> > > > qemu life-cycle (then pmem is not efficiently reused)?
> > > >
> > >
> > > It all depends on guests themselves. clwb/clflushopt/pcommit
> > > instructions are exposed to guest that are used by guests to make
> > > writes to pmem persistent.
> > >
> >
> > I meant from guest p.o.v, a range of pmem should be persistent
> > cross VM power on/off, i.e. the content needs to be maintained
> > somewhere so guest can get it at next power on...
> >
> > Thanks
> > Kevin
> 
> It's just like what we do for guest disk: as long as we always assign
> the same host pmem device or the same files on file systems on a host
> pmem device to the guest, the guest can find its last data on pmem.
> 
> Haozhong

This is the detail which I'd like to learn. If it's Qemu to request 
host pmem and then free when exit, the very pmem may be 
allocated to another process later. How do you achieve the 'as
long as'?

Thanks
Kevin