aboutsummaryrefslogtreecommitdiff
path: root/tests
diff options
context:
space:
mode:
authorZhang Yi <yi.z.zhang@linux.intel.com>2019-04-22 08:48:48 +0800
committerEduardo Habkost <ehabkost@redhat.com>2019-04-25 14:17:36 -0300
commit119906afa5ca610adb87c55ab0d8e53c9104bfc3 (patch)
treee4456a9bfacbad8b8caf7d1d4c3d478f4e37196f /tests
parent8cf108c5d159bccfa162a06e6abc35cfa4965781 (diff)
downloadqemu-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