Paolo Bonzini writes:
> Il 09/04/2013 10:52, Markus Armbruster ha scritto:
>>> > This also removes the need to do something special on valgrind
>>> > (see commit c2a8238a, Support running QEMU on Valgrind, 2011-10-31).
>> Suggest to state explicitly that you effectively revert it.
>>
>> You left
Paolo Bonzini wrote:
> 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
Il 09/04/2013 10:52, Markus Armbruster ha scritto:
>> > This also removes the need to do something special on valgrind
>> > (see commit c2a8238a, Support running QEMU on Valgrind, 2011-10-31).
> Suggest to state explicitly that you effectively revert it.
>
> You left #define CONFIG_VALGRIND in, ev
Paolo Bonzini writes:
> 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-introduce
Am 08.04.2013 um 12:47 schrieb Paolo Bonzini :
> 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 br
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, mig
