diff options
author | Paolo Bonzini <pbonzini@redhat.com> | 2013-04-09 17:43:43 +0200 |
---|---|---|
committer | Anthony Liguori <aliguori@us.ibm.com> | 2013-04-16 16:10:20 -0500 |
commit | 7dda5dc82a776a39a7996020c188eb2a29187117 (patch) | |
tree | d121e12b3639341ba18cef1e3d6f3d13e5fbd5b7 /rules.mak | |
parent | 86c7dba0d0ed1e9e202f77f7414ce0faf2395a90 (diff) | |
download | hqemu-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