All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yi Zhang <yi.z.zhang@linux.intel.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: xiaoguangrong.eric@gmail.com, stefanha@redhat.com,
	pbonzini@redhat.com, pagupta@redhat.com,
	yu.c.zhang@linux.intel.com, richardw.yang@linux.intel.com,
	ehabkost@redhat.com, qemu-devel@nongnu.org, imammedo@redhat.com,
	dan.j.williams@intel.com
Subject: Re: [Qemu-devel] [PATCH V12 5/5] docs: Added MAP_SYNC documentation
Date: Fri, 8 Feb 2019 18:07:08 +0800	[thread overview]
Message-ID: <20190208100707.GA61978@tiger-server> (raw)
In-Reply-To: <20190207092914-mutt-send-email-mst@kernel.org>

On 2019-02-07 at 09:30:12 -0500, Michael S. Tsirkin wrote:
> On Thu, Feb 07, 2019 at 11:16:05PM +0800, Yi Zhang wrote:
> > On 2019-02-06 at 13:29:37 -0500, Michael S. Tsirkin wrote:
> > > On Thu, Feb 07, 2019 at 01:27:29AM +0800, Zhang, Yi wrote:
> > > > From: Zhang Yi <yi.z.zhang@linux.intel.com>
> > > > 
> > > > Signed-off-by: Zhang Yi <yi.z.zhang@linux.intel.com>
> > > > ---
> > > >  docs/nvdimm.txt | 25 ++++++++++++++++++++++---
> > > >  qemu-options.hx |  4 ++++
> > > >  2 files changed, 26 insertions(+), 3 deletions(-)
> > > > 
> > > > diff --git a/docs/nvdimm.txt b/docs/nvdimm.txt
> > > > index 5f158a6..e2bf89f 100644
> > > > --- a/docs/nvdimm.txt
> > > > +++ b/docs/nvdimm.txt
> > > > @@ -143,9 +143,28 @@ Guest Data Persistence
> > > >  ----------------------
> > > >  
> > > >  Though QEMU supports multiple types of vNVDIMM backends on Linux,
> > > > -currently the only one that can guarantee the guest write persistence
> > > > -is the device DAX on the real NVDIMM device (e.g., /dev/dax0.0), to
> > > > -which all guest access do not involve any host-side kernel cache.
> > > > +the only backend that can guarantee the guest write persistence is:
> > > > +
> > > > +A. DAX device (e.g., /dev/dax0.0, ) or
> > > > +B. DAX file(mounted with dax option)
> > > > +
> > > > +both are from the real NVDIMM device, all guest access do not
> > > > +involve any host-side kernel cache.
Yes, A and B both based on the direct access for files/devices(no page cache)
> > > 
> > > I'm not sure - what do above 2 lines mean?
> > > That cache must not be used if persistence is desired?
> > same meaning of direct mapping of pmem, 
> > Ah, Maybe better to change to:
> > "both are backend from the real NVDIMM device, which supportting direct
> > mapping of persistent memory." ?
> 
> Yes but typos aside it is still unclear - what is this? An extra
> condition when persistence is guaranteed?
> 
> 
> > > 
> > > > +
> > > > +When using B (A file supporting direct mapping of persistent memory)
> > > > +as a backend, write persistence is guaranteed if the host kernel has
> > > > +support for the MAP_SYNC flag in the mmap system call (available
> > > > +since Linux 4.15 and on certain distro kernels) and additionally
> > > > +both 'pmem' and 'share' flags are set to 'on' on the backend.
> > > > +
> > > > +If these conditions are not satisfied i.e. if either 'pmem' or 'share'
> > > > +are not set, if the backend file does not support DAX or if MAP_SYNC
> > > > +is not supported by the host kernel, write persistence is not
> > > > +guaranteed after a system crash. For compatibility reasons, these
> > > > +conditions are silently ignored if not satisfied. Currently, no way
> > > > +is provided to test for them.
> > > > +For more details, please reference mmap(2) man page:
> > > > +http://man7.org/linux/man-pages/man2/mmap.2.html.
> > > >  
> > > >  When using other types of backends, it's suggested to set 'unarmed'
> > > >  option of '-device nvdimm' to 'on', which sets the unarmed flag of the
> > > > diff --git a/qemu-options.hx b/qemu-options.hx
> > > > index 08f8516..0cd41f4 100644
> > > > --- a/qemu-options.hx
> > > > +++ b/qemu-options.hx
> > > > @@ -4002,6 +4002,10 @@ using the SNIA NVM programming model (e.g. Intel NVDIMM).
> > > >  If @option{pmem} is set to 'on', QEMU will take necessary operations to
> > > >  guarantee the persistence of its own writes to @option{mem-path}
> > > >  (e.g. in vNVDIMM label emulation and live migration).
> > > > +Also, we will map the backend-file with MAP_SYNC flag, which can ensure
> > > 
> > > should be
> > > 	which ensures
> > > 
> > > > +the file metadata is in sync to @option{mem-path}
> > > 
> > > 
> > > should be
> > > 	for @option{mem-path}
> > > 
> > > > in case of host crash
> > > > +or a power failure. MAP_SYNC requires support from both the host kernel
> > > > +(since Linux kernel 4.15) and @option{mem-path}
> > > 
> > > 
> > > should be
> > > 	and the filesystem of @option{mem-path}
> > Thanks, will update it.
> > > 
> > > > (only files supporting DAX).
> > > >  
> > > >  @item -object memory-backend-ram,id=@var{id},merge=@var{on|off},dump=@var{on|off},share=@var{on|off},prealloc=@var{on|off},size=@var{size},host-nodes=@var{host-nodes},policy=@var{default|preferred|bind|interleave}
> > > >  
> > > > -- 
> > > > 2.7.4
> 

      reply	other threads:[~2019-02-08  1:36 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-06 17:25 [Qemu-devel] [PATCH V12 0/5] support MAP_SYNC for memory-backend-file Zhang, Yi
2019-02-06 17:26 ` [Qemu-devel] [PATCH V12 1/5] util/mmap-alloc: Add a 'is_pmem' parameter to qemu_ram_mmap Zhang, Yi
2019-02-06 17:27 ` [Qemu-devel] [PATCH V12 2/5] scripts/update-linux-headers: add linux/mman.h Zhang, Yi
2019-02-06 17:27 ` [Qemu-devel] [PATCH V12 3/5] linux-headers: " Zhang, Yi
2019-02-06 17:27 ` [Qemu-devel] [PATCH V12 4/5] util/mmap-alloc: support MAP_SYNC in qemu_ram_mmap() Zhang, Yi
2019-02-06 18:25   ` Michael S. Tsirkin
2019-02-06 17:27 ` [Qemu-devel] [PATCH V12 5/5] docs: Added MAP_SYNC documentation Zhang, Yi
2019-02-06 18:29   ` Michael S. Tsirkin
2019-02-07 15:16     ` Yi Zhang
2019-02-07 14:30       ` Michael S. Tsirkin
2019-02-08 10:07         ` Yi Zhang [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190208100707.GA61978@tiger-server \
    --to=yi.z.zhang@linux.intel.com \
    --cc=dan.j.williams@intel.com \
    --cc=ehabkost@redhat.com \
    --cc=imammedo@redhat.com \
    --cc=mst@redhat.com \
    --cc=pagupta@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=richardw.yang@linux.intel.com \
    --cc=stefanha@redhat.com \
    --cc=xiaoguangrong.eric@gmail.com \
    --cc=yu.c.zhang@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.