From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47610) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VeNAJ-0000Mu-7U for qemu-devel@nongnu.org; Thu, 07 Nov 2013 05:50:25 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VeNAC-0001u2-VJ for qemu-devel@nongnu.org; Thu, 07 Nov 2013 05:50:19 -0500 Received: from mail-la0-f50.google.com ([209.85.215.50]:47230) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VeNAC-0001sx-P4 for qemu-devel@nongnu.org; Thu, 07 Nov 2013 05:50:12 -0500 Received: by mail-la0-f50.google.com with SMTP id eo20so287876lab.9 for ; Thu, 07 Nov 2013 02:50:11 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <1383820884-29596-2-git-send-email-marcel.a@redhat.com> References: <1383820884-29596-1-git-send-email-marcel.a@redhat.com> <1383820884-29596-2-git-send-email-marcel.a@redhat.com> From: Peter Maydell Date: Thu, 7 Nov 2013 10:49:50 +0000 Message-ID: Content-Type: text/plain; charset=UTF-8 Subject: Re: [Qemu-devel] [PATCH for-1.7 v2 1/8] exec: declare TARGET_PHYS_ADDR_SPACE_MAX to limit memory regions rendered by exec List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Marcel Apfelbaum Cc: Alexander Graf , Eduardo Habkost , "Michael S. Tsirkin" , Jan Kiszka , QEMU Developers , Luiz Capitulino , Anthony Liguori , Paolo Bonzini , =?UTF-8?Q?Andreas_F=C3=A4rber?= On 7 November 2013 10:41, Marcel Apfelbaum wrote: > The page table logic in exec.c assumes > that memory addresses are at most TARGET_PHYS_ADDR_SPACE_BITS. > Use TARGET_PHYS_ADDR_SPACE_MAX as max size for memory regions > rendered by exec. > > Signed-off-by: Marcel Apfelbaum > --- > include/exec/address-spaces.h | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/include/exec/address-spaces.h b/include/exec/address-spaces.h > index 3d12cdd..174cc05 100644 > --- a/include/exec/address-spaces.h > +++ b/include/exec/address-spaces.h > @@ -23,6 +23,10 @@ > > #ifndef CONFIG_USER_ONLY > > +#define TARGET_PHYS_ADDR_SPACE_MAX \ > + (TARGET_PHYS_ADDR_SPACE_BITS == 64 ? \ > + UINT64_MAX : (0x1ULL << TARGET_PHYS_ADDR_SPACE_BITS)) > + I think it's worth adding a comment that this is a size intended for use in memory_region_init() calls and so follows the odd convention used by that API that it is a size in bytes with the exception that UINT64_MAX represents 2^64. (it follows from this that using the #define anywhere except in a memory_region_init() call is probably a bug) -- PMM