From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57813) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vd5Bq-0003XD-5q for qemu-devel@nongnu.org; Sun, 03 Nov 2013 16:26:40 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vd5Bk-0001X9-5L for qemu-devel@nongnu.org; Sun, 03 Nov 2013 16:26:34 -0500 Received: from mail-la0-f45.google.com ([209.85.215.45]:39738) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vd5Bj-0001Wt-UG for qemu-devel@nongnu.org; Sun, 03 Nov 2013 16:26:28 -0500 Received: by mail-la0-f45.google.com with SMTP id hp15so4899960lab.32 for ; Sun, 03 Nov 2013 13:26:27 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <1383511723-11228-1-git-send-email-marcel.a@redhat.com> References: <1383511723-11228-1-git-send-email-marcel.a@redhat.com> From: Peter Maydell Date: Sun, 3 Nov 2013 21:26:06 +0000 Message-ID: Content-Type: text/plain; charset=UTF-8 Subject: Re: [Qemu-devel] [PATCH] exec: fix regression by making system-memory region UINT64_MAX size List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Marcel Apfelbaum Cc: "Michael S. Tsirkin" , Jan Kiszka , QEMU Developers , Anthony Liguori , Paolo Bonzini , =?UTF-8?Q?Andreas_F=C3=A4rber?= , Richard Henderson On 3 November 2013 20:48, Marcel Apfelbaum wrote: > The problem appears when a root memory region within an > address space with size < UINT64_MAX has overlapping children > with the same size. If the size of the root memory region is UINT64_MAX > everyting is ok. > > Solved the regression by making the system-memory region > of size UINT64_MAX instead of INT64_MAX. > > Signed-off-by: Marcel Apfelbaum > --- > In the mean time I am investigating why the > root memory region has to be UINT64_MAX size in order > to have overlapping children > system_memory = g_malloc(sizeof(*system_memory)); > - memory_region_init(system_memory, NULL, "system", INT64_MAX); > + memory_region_init(system_memory, NULL, "system", UINT64_MAX); > address_space_init(&address_space_memory, system_memory, "memory"); As you say above we should investigate why this caused a problem, but I was surprised the system memory space isn't already maximum size. It turns out that that change was introduced in commit 8417cebf in an attempt to avoid overflow issues by sticking to signed 64 bit arithmetic. This approach was subsequently ditched in favour of using proper 128 bit arithmetic in commit 08dafab4, but we never changed the init call for the system memory back to UINT64_MAX. So I think this is a good change in itself. -- PMM