Re: [Xen-devel] [RFC Design Doc] Add vNVDIMM support for Xen

["Zhang, Haozhong" <haozhong.zhang@xxxxxxxxx>]

On 02/02/16 16:03, Tian, Kevin wrote:
> > 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'?
> 

QEMU receives following parameters

     -object memory-backend-file,id=mem1,share,mem-path=/dev/pmem0,size=10G \
     -device nvdimm,memdev=mem1,id=nv1
     
that configs a vNVDIMM device backed by the host pmem device
/dev/pmem0. It can also be replaced by files on the file system on
/dev/pmem0. The system address space range occupied by /dev/pmem0 or
files on /dev/pmem0 are then mapped into the guest physical address
space, and all accesses from guest are then directly applied on the
host device without any interception of QEMU.

If we always provide the same vNVDIMM parameters (specially mem-path
and size), the guest can observe the same vNVDIMM devices across
boot.

In Xen, I'll implement the similar configuration options in xl.cfg, e.g.
     nvdimms = [ '/dev/pmem0', '/dev/pmem1', '/mnt/pmem2/file_on_pmem2' ]

Haozhong

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel