From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39941) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UpgF6-0003XC-EG for qemu-devel@nongnu.org; Thu, 20 Jun 2013 10:53:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UpgF1-0001fh-Lu for qemu-devel@nongnu.org; Thu, 20 Jun 2013 10:53:44 -0400 Received: from mx1.redhat.com ([209.132.183.28]:44731) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UpgF1-0001fV-Ec for qemu-devel@nongnu.org; Thu, 20 Jun 2013 10:53:39 -0400 Message-ID: <51C3176B.2080802@redhat.com> Date: Thu, 20 Jun 2013 16:53:31 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1369947836-2638-1-git-send-email-pbonzini@redhat.com> <1369947836-2638-8-git-send-email-pbonzini@redhat.com> <51C30F85.400@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 07/22] memory: add address_space_translate List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: qemu-devel@nongnu.org Il 20/06/2013 16:43, Peter Maydell ha scritto: >>> >> There are other places in memory.c which do an int128_get64() >>> >> on mr->size, which also look suspicious... >> > >> > They are all on I/O regions so they are safe > Not entirely sure I understand this. There's no particular > reason I can't create a 2^64 sized I/O memory region > and put it in an address space, is there? I think there are problems in the core if you do that (probably part of it is fixed now). Still, in cases like this: memory_region_add_coalescing(mr, 0, int128_get64(mr->size)); the API simply doesn't support it. Paolo