summaryrefslogtreecommitdiffstats
path: root/rules.mak
diff options
context:
space:
mode:
authorPaolo Bonzini <pbonzini@redhat.com>2013-04-09 17:43:43 +0200
committerAnthony Liguori <aliguori@us.ibm.com>2013-04-16 16:10:20 -0500
commit7dda5dc82a776a39a7996020c188eb2a29187117 (patch)
treed121e12b3639341ba18cef1e3d6f3d13e5fbd5b7 /rules.mak
parent86c7dba0d0ed1e9e202f77f7414ce0faf2395a90 (diff)
downloadhqemu-7dda5dc82a776a39a7996020c188eb2a29187117.zip
hqemu-7dda5dc82a776a39a7996020c188eb2a29187117.tar.gz
migration: initialize RAM to zero
Using qemu_memalign only leaves the RAM zero by chance, because libc will usually use mmap to satisfy our huge requests. But memory will not be zero when using MALLOC_PERTURB_ with a nonzero value. In the case of incoming migration, this breaks a recently-introduced invariant (commit f1c7279, migration: do not sent zero pages in bulk stage, 2013-03-26). To fix this, use mmap ourselves to get a well-aligned, always zero block for the RAM. Mmap-ed memory is easy to "trim" at the sides. This also removes the need to do something special on valgrind (see commit c2a8238a, Support running QEMU on Valgrind, 2011-10-31), thus effectively reverts that patch. Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Message-id: 1365522223-20153-1-git-send-email-pbonzini@redhat.com Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Diffstat (limited to 'rules.mak')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud