From: Wei Yang <richardw.yang@linux.intel.com> To: qemu-devel@nongnu.org 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, mst@redhat.com, ehabkost@redhat.com, imammedo@redhat.com, dan.j.williams@intel.com, yi.z.zhang@linux.intel.com Subject: [Qemu-devel] [PATCH v14 2/2] docs: Added MAP_SYNC documentation Date: Mon, 22 Apr 2019 08:48:49 +0800 [thread overview] Message-ID: <20190422004849.26463-3-richardw.yang@linux.intel.com> (raw) In-Reply-To: <20190422004849.26463-1-richardw.yang@linux.intel.com> From: Zhang Yi <yi.z.zhang@linux.intel.com> Signed-off-by: Zhang Yi <yi.z.zhang@linux.intel.com> --- docs/nvdimm.txt | 22 +++++++++++++++++++--- qemu-options.hx | 5 +++++ 2 files changed, 24 insertions(+), 3 deletions(-) diff --git a/docs/nvdimm.txt b/docs/nvdimm.txt index 7231c2d78f..bcd1456e72 100644 --- a/docs/nvdimm.txt +++ b/docs/nvdimm.txt @@ -144,9 +144,25 @@ 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) + +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 08749a3391..bdc74c0620 100644 --- a/qemu-options.hx +++ b/qemu-options.hx @@ -4233,6 +4233,11 @@ 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 ensures the +file metadata is in sync 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 the filesystem of @option{mem-path} mounted +with DAX option. @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.19.1
WARNING: multiple messages have this Message-ID (diff)
From: Wei Yang <richardw.yang@linux.intel.com> To: qemu-devel@nongnu.org Cc: pagupta@redhat.com, xiaoguangrong.eric@gmail.com, mst@redhat.com, yi.z.zhang@linux.intel.com, yu.c.zhang@linux.intel.com, richardw.yang@linux.intel.com, stefanha@redhat.com, imammedo@redhat.com, pbonzini@redhat.com, dan.j.williams@intel.com, ehabkost@redhat.com Subject: [Qemu-devel] [PATCH v14 2/2] docs: Added MAP_SYNC documentation Date: Mon, 22 Apr 2019 08:48:49 +0800 [thread overview] Message-ID: <20190422004849.26463-3-richardw.yang@linux.intel.com> (raw) Message-ID: <20190422004849.sIolv_GQJwqSk3Ra8l8pQfTq_35tDaTowSOhjq-XNbM@z> (raw) In-Reply-To: <20190422004849.26463-1-richardw.yang@linux.intel.com> From: Zhang Yi <yi.z.zhang@linux.intel.com> Signed-off-by: Zhang Yi <yi.z.zhang@linux.intel.com> --- docs/nvdimm.txt | 22 +++++++++++++++++++--- qemu-options.hx | 5 +++++ 2 files changed, 24 insertions(+), 3 deletions(-) diff --git a/docs/nvdimm.txt b/docs/nvdimm.txt index 7231c2d78f..bcd1456e72 100644 --- a/docs/nvdimm.txt +++ b/docs/nvdimm.txt @@ -144,9 +144,25 @@ 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) + +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 08749a3391..bdc74c0620 100644 --- a/qemu-options.hx +++ b/qemu-options.hx @@ -4233,6 +4233,11 @@ 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 ensures the +file metadata is in sync 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 the filesystem of @option{mem-path} mounted +with DAX option. @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.19.1
next prev parent reply other threads:[~2019-04-22 0:55 UTC|newest] Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-04-22 0:48 [Qemu-devel] [PATCH v14 0/2] support MAP_SYNC for memory-backend-file Wei Yang 2019-04-22 0:48 ` Wei Yang 2019-04-22 0:48 ` [Qemu-devel] [PATCH v14 1/2] util/mmap-alloc: support MAP_SYNC in qemu_ram_mmap() Wei Yang 2019-04-22 0:48 ` Wei Yang 2019-04-23 9:25 ` Stefan Hajnoczi 2019-04-23 9:25 ` Stefan Hajnoczi 2019-04-24 1:01 ` Wei Yang 2019-04-24 1:01 ` Wei Yang 2019-04-25 8:26 ` Stefan Hajnoczi 2019-04-25 8:26 ` Stefan Hajnoczi 2019-04-22 0:48 ` Wei Yang [this message] 2019-04-22 0:48 ` [Qemu-devel] [PATCH v14 2/2] docs: Added MAP_SYNC documentation Wei Yang 2019-04-23 9:26 ` Stefan Hajnoczi 2019-04-23 9:26 ` Stefan Hajnoczi 2019-04-23 9:57 ` Pankaj Gupta 2019-04-23 9:57 ` Pankaj Gupta 2019-04-22 12:34 ` [Qemu-devel] [PATCH v14 0/2] support MAP_SYNC for memory-backend-file Michael S. Tsirkin 2019-04-22 12:34 ` Michael S. Tsirkin 2019-04-22 18:22 ` Eduardo Habkost 2019-04-22 18:22 ` Eduardo Habkost 2019-04-23 2:41 ` Wei Yang 2019-04-23 2:41 ` Wei Yang 2019-04-23 12:43 ` Michael S. Tsirkin 2019-04-23 12:43 ` Michael S. Tsirkin
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=20190422004849.26463-3-richardw.yang@linux.intel.com \ --to=richardw.yang@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=stefanha@redhat.com \ --cc=xiaoguangrong.eric@gmail.com \ --cc=yi.z.zhang@linux.intel.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: linkBe 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.