mii/qemu
1
0
Fork 0
mirror of https://github.com/mii443/qemu.git synced 2025-08-25 00:19:36 +00:00
Code Issues Packages Projects Releases Wiki Activity

Merge remote-tracking branch 'remotes/ehabkost/tags/machine-next-pull-request' into staging

Browse Source 
Machine queue, 2019-04-25

* 4.1 machine-types (Cornelia Huck)
* Support MAP_SYNC on pmem memory backends (Zhang Yi)
* -cpu parsing fixes and cleanups (Eduardo Habkost)
* machine initialization cleanups (Wei Yang, Markus Armbruster)

# gpg: Signature made Thu 25 Apr 2019 18:54:57 BST
# gpg:                using RSA key 2807936F984DC5A6
# gpg: Good signature from "Eduardo Habkost <ehabkost@redhat.com>" [full]
# Primary key fingerprint: 5A32 2FD5 ABC4 D3DB ACCF  D1AA 2807 936F 984D C5A6

* remotes/ehabkost/tags/machine-next-pull-request:
  util/mmap-alloc: support MAP_SYNC in qemu_ram_mmap()
  linux-headers: add linux/mman.h.
  scripts/update-linux-headers: add linux/mman.h
  util/mmap-alloc: Add a 'is_pmem' parameter to qemu_ram_mmap
  cpu: Fix crash with empty -cpu option
  cpu: Rename parse_cpu_model() to parse_cpu_option()
  vl: Simplify machine_parse()
  vl: Clean up after previous commit
  vl.c: allocate TYPE_MACHINE list once during bootup
  vl.c: make find_default_machine() local
  hw: add compat machines for 4.1

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
This commit is contained in:
Peter Maydell
2019-04-26 14:30:18 +01:00
parent f7526eece2 119906afa5
commit 06e6433955
31 changed files with 593 additions and 77 deletions
Download Patch File Download Diff File Expand all files Collapse all files

22
docs/nvdimm.txt
View File

@ -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 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