From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51691) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VeNQm-0007cL-Bw for qemu-devel@nongnu.org; Thu, 07 Nov 2013 06:07:26 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VeNQg-0007Xm-Dw for qemu-devel@nongnu.org; Thu, 07 Nov 2013 06:07:20 -0500 Received: from cantor2.suse.de ([195.135.220.15]:45867 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VeNQg-0007XY-7U for qemu-devel@nongnu.org; Thu, 07 Nov 2013 06:07:14 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1812\)) From: Alexander Graf In-Reply-To: <1383820884-29596-1-git-send-email-marcel.a@redhat.com> Date: Thu, 7 Nov 2013 12:07:08 +0100 Content-Transfer-Encoding: 7bit Message-Id: <3815E535-F3B4-4C15-B726-B6D24AF80ED5@suse.de> References: <1383820884-29596-1-git-send-email-marcel.a@redhat.com> Subject: Re: [Qemu-devel] [PATCH for-1.7 v2 0/8] fix address space size issue List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Marcel Apfelbaum Cc: Peter Maydell , Eduardo Habkost , "Michael S. Tsirkin" , Jan Kiszka , QEMU Developers , Luiz Capitulino , aliguori@amazon.com, Paolo Bonzini , =?iso-8859-1?Q?Andreas_F=E4rber?= On 07.11.2013, at 11:41, Marcel Apfelbaum wrote: > A bug reported by Luiz Capitulino let us to find > several bugs in memory address space setup. > > One issue is that gdb stub can give us arbitrary addresses > and we'll try to access them. > Since our lookup ignored high bits in the address, > we hit a wrong section and got a crash. > In fact, PCI devices can access arbitrary addresses too, > so we should just make lookup robust against this case. > > Another issue has to do with size of regions. > memory API uses UINT64_MAX so say "all 64 bit" but > some devices mistakenly used INT64_MAX. > > It should not affect most systems in practice as > everything should be limited by address space size, > but it's an API misuse that we should not keep around, > and it will become a problem if a system with 64 bit > target address hits this path. > > Patch 1 introduces TARGET_PHYS_ADDR_SPACE_MAX that is > the max size for memory regions rendered by exec. > Patches 2-3 limits the size of memory regions used by exec.c. > Patch 4 fixes an actual bug. > The rest of patches make code cleaner and more robust. ppc bits are: Acked-by: Alexander Graf Alex