Red Hat Bugzilla – Bug 1425151
qemu zeroes the first byte of NVDIMM on initialization
Last modified: 2017-08-01 23:37:31 EDT
Description of problem: When developing patches for libvirt I've noticed that qemu zeroes the very first byte of file associated with NVDIMM. This happens only if -mem-prealloc is specified (or prealloc=yes is set for the corresponding memory-backend-file object). Version-Release number of selected component (if applicable): qemu-kvm-common-rhev-2.6.0-28.el7_3.6.x86_64 qemu-kvm-rhev-2.6.0-28.el7_3.6.x86_64 How reproducible: 100% Steps to Reproduce: 1. echo -n 'A' > /tmp/nvdimm.dat 2. truncate -s 10M /tmp/nvdimm.dat 3. hexdump -C /tmp/nvdimm.dat 00000000 41 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |A...............| 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00a00000 4. /usr/libexec/qemu-kvm -mem-prealloc -machine pc,nvdimm -m 1024,slots=4,maxmem=8G -cpu host -object memory-backend-file,id=mem1,share=on,mem-path=/tmp/nvdimm.dat,size=$((10 * 1024 * 1024)) -device nvdimm,id=nvdimm1,memdev=mem1 Could not access KVM kernel module: No such file or directory failed to initialize KVM: No such file or directory Back to tcg accelerator. qemu-kvm: CPU model 'host' requires KVM 5. hexdump -C /tmp/nvdimm.dat 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00a00000 Actual results: Expected results: Additional info: From my IRC discussion with qemu developers (danpb and stefanha) it looks like the problem is occurring in os_mem_prealloc() which writes one byte of a value zero. Ideally, the fix would not increase wear level of NVDIMMs.
Fixed by the following upstream patch in QEMU 2.9.0-rc1: commit 9dc44aa5829eb3131a01378a738dee28a382bbc1 Author: Daniel P. Berrange <berrange@redhat.com> Date: Fri Mar 3 11:32:55 2017 +0000 os: don't corrupt pre-existing memory-backend data with prealloc
Reproduce: qemu-kvm-rhev-2.8.0-6.el7 kernel-3.10.0-655.el7.x86_64 Steps: 1. # echo -n 'A' > /tmp/nvdimm.dat 2. # truncate -s 10M /tmp/nvdimm.dat 3. # hexdump -C /tmp/nvdimm.dat 00000000 41 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |A...............| 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00a00000 4. # /usr/libexec/qemu-kvm -m 4G,slots=40,maxmem=40G \ -drive file=rhel74.qcow2,if=none,id=drive-virtio-disk0,format=qcow2,cache=none -device virtio-blk-pci,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 \ -netdev tap,id=idinWyYp -device virtio-net-pci,mac=42:ce:a9:d2:4d:d7,id=idlbq7eA,netdev=idinWyYp \ -vnc :0 -monitor stdio -machine pc,nvdimm \ -object memory-backend-file,id=mem1,share=on,mem-path=/tmp/nvdimm.dat,size=$((10 * 1024 * 1024)) -device nvdimm,id=nvdimm1,memdev=mem1 \ -mem-prealloc 5. # hexdump -C /tmp/nvdimm.dat 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00a00000 Verify: qemu-kvm-rhev-2.9.0-1.el7 kernel-3.10.0-655.el7.x86_64 With same steps as above, after step5, # hexdump -C /tmp/nvdimm.dat 00000000 41 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |A...............| 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00a00000 The first byte of the file is not changed. So the bug is fixed.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2017:2392