From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:49259) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UPUIS-0005Jz-PO for qemu-devel@nongnu.org; Tue, 09 Apr 2013 04:52:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UPUIR-0002Ek-Fm for qemu-devel@nongnu.org; Tue, 09 Apr 2013 04:52:56 -0400 Received: from mx1.redhat.com ([209.132.183.28]:53460) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UPUIR-0002Dm-7f for qemu-devel@nongnu.org; Tue, 09 Apr 2013 04:52:55 -0400 From: Markus Armbruster References: <1365418028-2546-1-git-send-email-pbonzini@redhat.com> Date: Tue, 09 Apr 2013 10:52:46 +0200 In-Reply-To: <1365418028-2546-1-git-send-email-pbonzini@redhat.com> (Paolo Bonzini's message of "Mon, 8 Apr 2013 12:47:08 +0200") Message-ID: <87ip3wm6g1.fsf@blackfin.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] [PATCH] migration: initialize RAM to zero List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: kwolf@redhat.com, aliguori@us.ibm.com, quintela@redhat.com, stefanha@gmail.com, pl@kamp.de, qemu-devel@nongnu.org, owasserm@redhat.com 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-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). Suggest to state explicitly that you effectively revert it. You left #define CONFIG_VALGRIND in, even though it's no longer used. Intentional? > Signed-off-by: Paolo Bonzini > --- > util/oslib-posix.c | 30 +++++++++++++----------------- > 1 file changed, 13 insertions(+), 17 deletions(-) > > diff --git a/util/oslib-posix.c b/util/oslib-posix.c > index 433dd68..91f5aab 100644 > --- a/util/oslib-posix.c > +++ b/util/oslib-posix.c > @@ -52,12 +52,8 @@ extern int daemon(int, int); > #include "sysemu/sysemu.h" > #include "trace.h" > #include "qemu/sockets.h" > +#include > > -#if defined(CONFIG_VALGRIND) > -static int running_on_valgrind = -1; > -#else > -# define running_on_valgrind 0 > -#endif > #ifdef CONFIG_LINUX > #include > #endif > @@ -108,22 +104,22 @@ void *qemu_memalign(size_t alignment, size_t size) > /* alloc shared memory pages */ > void *qemu_vmalloc(size_t size) > { > - void *ptr; > size_t align = QEMU_VMALLOC_ALIGN; > + size_t total = size + align - getpagesize(); > + void *ptr = mmap(0, total, PROT_READ | PROT_WRITE, > + MAP_ANONYMOUS | MAP_PRIVATE, -1, 0); > + size_t offset = QEMU_ALIGN_UP((uintptr_t)ptr, align) - (uintptr_t)ptr; > > -#if defined(CONFIG_VALGRIND) > - if (running_on_valgrind < 0) { > - /* First call, test whether we are running on Valgrind. > - This is a substitute for RUNNING_ON_VALGRIND from valgrind.h. */ > - const char *ld = getenv("LD_PRELOAD"); > - running_on_valgrind = (ld != NULL && strstr(ld, "vgpreload")); > - } > -#endif Please check for mmap() failure. The old code uses qemu_memalign(), which treats allocation failure as a programming error: calls abort(). Not sure that's actually appropriate here. > + ptr += offset; > + total -= offset; > > - if (size < align || running_on_valgrind) { > - align = getpagesize(); > + if (offset > 0) { > + munmap(ptr - offset, offset); > + } > + if (total > size) { > + munmap(ptr + size, total - size); > } > - ptr = qemu_memalign(align, size); > + > trace_qemu_vmalloc(size, ptr); > return ptr; > }