diff options
author | Zhang Yi <yi.z.zhang@linux.intel.com> | 2019-04-22 08:48:48 +0800 |
---|---|---|
committer | Eduardo Habkost <ehabkost@redhat.com> | 2019-04-25 14:17:36 -0300 |
commit | 119906afa5ca610adb87c55ab0d8e53c9104bfc3 (patch) | |
tree | e4456a9bfacbad8b8caf7d1d4c3d478f4e37196f /tests | |
parent | 8cf108c5d159bccfa162a06e6abc35cfa4965781 (diff) | |
download | qemu-119906afa5ca610adb87c55ab0d8e53c9104bfc3.zip qemu-119906afa5ca610adb87c55ab0d8e53c9104bfc3.tar.gz qemu-119906afa5ca610adb87c55ab0d8e53c9104bfc3.tar.bz2 |
util/mmap-alloc: support MAP_SYNC in qemu_ram_mmap()
When a file supporting DAX is used as vNVDIMM backend, mmap it with
MAP_SYNC flag in addition which can ensure file system metadata
synced in each guest writes to the backend file, without other QEMU
actions (e.g., periodic fsync() by QEMU).
Current, We have below different possible use cases:
1. pmem=on is set, shared=on is set, MAP_SYNC supported:
a: backend is a dax supporting file.
- MAP_SYNC will active.
b: backend is not a dax supporting file.
- mmap will trigger a warning. then MAP_SYNC flag will be ignored
2. The rest of cases:
- we will never pass the MAP_SYNC to mmap2
Signed-off-by: Haozhong Zhang <haozhong.zhang@intel.com>
Signed-off-by: Zhang Yi <yi.z.zhang@linux.intel.com>
[ehabkost: Rebased patch to latest code on master]
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Wei Yang <richardw.yang@linux.intel.com>
Tested-by: Wei Yang <richardw.yang@linux.intel.com>
Message-Id: <20190422004849.26463-2-richardw.yang@linux.intel.com>
[ehabkost: squashed documentation patch]
Message-Id: <20190422004849.26463-3-richardw.yang@linux.intel.com>
[ehabkost: documentation fixup]
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Pankaj Gupta <pagupta@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Diffstat (limited to 'tests')
0 files changed, 0 insertions, 0 deletions