[Qemu-devel] [PATCH V7 0/6] nvdimm: support MAP_SYNC for memory-backend-file

Zhang Yi posted 6 patches 5 years, 4 months ago
Failed in applying to current master (apply log)
backends/hostmem-file.c   | 45 +++++++++++++++++++++++++++++++++++++++++++--
backends/hostmem.c        |  8 +++++---
docs/nvdimm.txt           | 22 +++++++++++++++++++++-
exec.c                    |  9 +++++----
include/exec/memory.h     | 18 ++++++++++++++++++
include/exec/ram_addr.h   |  1 +
include/qemu/mmap-alloc.h | 20 +++++++++++++++++++-
include/qemu/osdep.h      | 29 +++++++++++++++++++++++++++++
numa.c                    |  1 +
qemu-options.hx           | 22 +++++++++++++++++++++-
util/mmap-alloc.c         | 27 ++++++++++++++++++++++-----
util/oslib-posix.c        |  8 +++++++-
12 files changed, 192 insertions(+), 18 deletions(-)
[Qemu-devel] [PATCH V7 0/6] nvdimm: support MAP_SYNC for memory-backend-file
Posted by Zhang Yi 5 years, 4 months ago
Linux 4.15 introduces a new mmap flag MAP_SYNC, which can be used to
guarantee the write persistence to mmap'ed files supporting DAX (e.g.,
files on ext4/xfs file system mounted with '-o dax').

A description of MAP_SYNC and MAP_SHARED_VALIDATE can be found at
    https://patchwork.kernel.org/patch/10028151/

In order to make sure that the file metadata is in sync after a fault 
while we are writing a shared DAX supporting backend files, this
patch-set enables QEMU to use MAP_SYNC flag for memory-backend-dax-file.

As the DAX vs DMA truncated issue was solved, we refined the code and
send out this feature for the v5 version.

A new auto on/off option 'sync' is added to memory-backend-file:
 - on:  try to pass MAP_SYNC to mmap(2); if MAP_SYNC is not supported or
        'share=off' or 'pmem=off', QEMU will abort
 - off: never pass MAP_SYNC to mmap(2)
 - auto (default): if MAP_SYNC is supported and 'share=on' 'pmem=on', work as if
        'sync=on'; otherwise, work as if 'sync=off'

Changes in v7:
 * Micheal: [3,4,6]/6 limited the "sync" flag only on a nvdimm backend.(pmem=on)

Changes in v6:
 * Pankaj: 3/7 are squashed with 2/7
 * Pankaj: 7/7 update comments to "consistent filesystem metadata".
 * Pankaj, Igor: 1/7 Added Reviewed-by in patch-1/7
 * Stefan, 4/7 move the include header from "/linux/mman.h" to "osdep.h"
 * Stefan, 5/7 Add missing "munmap"
 * Stefan, 2/7 refine the shared/flag.

Changes in v5:
 * Add patch 1 to fix a memory leak issue.
 * Refine the patch 4-6
 * Remove the patch 3 as we already change the parameter from "shared" to
   "flags"

Changes in v4:
 * Add patch 1-3 to switch some functions to a single 'flags'
   parameters. (Michael S. Tsirkin)
 * v3 patch 1-3 become v4 patch 4-6.
 * Patch 4: move definitions of MAP_SYNC and MAP_SHARED_VALIDATE to a
   new header file under include/standard-headers/linux/. (Michael S. Tsirkin)
 * Patch 6: refine the description of the 'sync' option. (Michael S. Tsirkin)

Changes in v3:
 * Patch 1: add MAP_SHARED_VALIDATE in both sync=on and sync=auto
   cases, and add back the retry mechanism. MAP_SYNC will be ignored
   by Linux kernel 4.15 if MAP_SHARED_VALIDATE is missed.
 * Patch 1: define MAP_SYNC and MAP_SHARED_VALIDATE as 0 on non-Linux
   platforms in order to make qemu_ram_mmap() compile on those platforms.
 * Patch 2&3: include more information in error messages of
   memory-backend in hope to help user to identify the error.
   (Dr. David Alan Gilbert)
 * Patch 3: fix typo in the commit message. (Dr. David Alan Gilbert)

Changes in v2:
 * Add 'sync' option to control the use of MAP_SYNC. (Eduardo Habkost)
 * Remove the unnecessary set of MAP_SHARED_VALIDATE in some cases and
   the retry mechanism in qemu_ram_mmap(). (Michael S. Tsirkin)
 * Move OS dependent definitions of MAP_SYNC and MAP_SHARED_VALIDATE
   to osdep.h. (Michael S. Tsirkin)

Zhang Yi (6):
  numa: Fixed the memory leak of numa error message
  util/mmap-alloc: switch qemu_ram_mmap() to 'flags' parameter
  util/mmap-alloc: support MAP_SYNC in qemu_ram_mmap()
  util/mmap-alloc: Switch the RAM_SYNC flags to OnOffAuto
  hostmem: add more information in error messages
  hostmem-file: add 'sync' option

 backends/hostmem-file.c   | 45 +++++++++++++++++++++++++++++++++++++++++++--
 backends/hostmem.c        |  8 +++++---
 docs/nvdimm.txt           | 22 +++++++++++++++++++++-
 exec.c                    |  9 +++++----
 include/exec/memory.h     | 18 ++++++++++++++++++
 include/exec/ram_addr.h   |  1 +
 include/qemu/mmap-alloc.h | 20 +++++++++++++++++++-
 include/qemu/osdep.h      | 29 +++++++++++++++++++++++++++++
 numa.c                    |  1 +
 qemu-options.hx           | 22 +++++++++++++++++++++-
 util/mmap-alloc.c         | 27 ++++++++++++++++++++++-----
 util/oslib-posix.c        |  8 +++++++-
 12 files changed, 192 insertions(+), 18 deletions(-)

-- 
2.7.4


Re: [Qemu-devel] [PATCH V7 0/6] nvdimm: support MAP_SYNC for memory-backend-file
Posted by Stefan Hajnoczi 5 years, 4 months ago
On Tue, Dec 18, 2018 at 04:16:44PM +0800, Zhang Yi wrote:
> Linux 4.15 introduces a new mmap flag MAP_SYNC, which can be used to
> guarantee the write persistence to mmap'ed files supporting DAX (e.g.,
> files on ext4/xfs file system mounted with '-o dax').
> 
> A description of MAP_SYNC and MAP_SHARED_VALIDATE can be found at
>     https://patchwork.kernel.org/patch/10028151/
> 
> In order to make sure that the file metadata is in sync after a fault 
> while we are writing a shared DAX supporting backend files, this
> patch-set enables QEMU to use MAP_SYNC flag for memory-backend-dax-file.
> 
> As the DAX vs DMA truncated issue was solved, we refined the code and
> send out this feature for the v5 version.
> 
> A new auto on/off option 'sync' is added to memory-backend-file:
>  - on:  try to pass MAP_SYNC to mmap(2); if MAP_SYNC is not supported or
>         'share=off' or 'pmem=off', QEMU will abort
>  - off: never pass MAP_SYNC to mmap(2)
>  - auto (default): if MAP_SYNC is supported and 'share=on' 'pmem=on', work as if
>         'sync=on'; otherwise, work as if 'sync=off'

I took a quick look and didn't see human-readable errors when pmem=off.
Is it possible to report it instead of aborting?

Thanks,
Stefan