From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L9pjz-0008L3-C3 for qemu-devel@nongnu.org; Mon, 08 Dec 2008 18:42:15 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L9pjy-0008Kk-Rh for qemu-devel@nongnu.org; Mon, 08 Dec 2008 18:42:15 -0500 Received: from [199.232.76.173] (port=39941 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L9pjy-0008Kg-OU for qemu-devel@nongnu.org; Mon, 08 Dec 2008 18:42:14 -0500 Received: from mx20.gnu.org ([199.232.41.8]:22755) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1L9pjy-0005pv-DI for qemu-devel@nongnu.org; Mon, 08 Dec 2008 18:42:14 -0500 Received: from mail.codesourcery.com ([65.74.133.4]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1L9pjx-0004Em-E7 for qemu-devel@nongnu.org; Mon, 08 Dec 2008 18:42:13 -0500 From: Paul Brook Subject: Re: [Qemu-devel] [PATCH] Rewrite mmap_find_vma() to work fine on 64-bit hosts with 32-bit targets Date: Mon, 8 Dec 2008 23:42:10 +0000 References: <1228303789-25653-1-git-send-email-kirill@shutemov.name> <20081203125057.GA29192@epbyminw8406h.minsk.epam.com> <20081208204815.GA6724@epbyminw8406h.minsk.epam.com> In-Reply-To: <20081208204815.GA6724@epbyminw8406h.minsk.epam.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200812082342.11253.paul@codesourcery.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Martin Mohring , "Kirill A. Shutemov" On Monday 08 December 2008, Kirill A. Shutemov wrote: > On Wed, Dec 03, 2008 at 02:50:57PM +0200, Kirill A. Shutemov wrote: > > On Wed, Dec 03, 2008 at 12:34:18PM +0000, Paul Brook wrote: > > > On Wednesday 03 December 2008, Kirill A. Shutemov wrote: > > > > qemu's page table can be incomple if /proc/self/maps is unavailable > > > > or host allocating a memory with mmap(), so we can't use it to find > > > > free memory area. > > > > > > Do we really care? Do such systems exist? > > > > I use qemu-arm to build packages in restricted environment -- in > > hasher[1]. hasher mounts /proc only for packages that really need it for > > building (java, for example). > > > > [1] http://en.altlinux.org/Hasher > > Paul, do you have any objection or not? I really want to see it into > upstream. My objection is that we're replacing a fairly deterministic code that maintains an address map with something that uses host mmap fairly aggressively to do probing. I'm not sure this is a good thing. I'm a bit worried that we've now got a strange mix of code that "knows" which areas are available and code that does probing. I'm also a bit worried about the overhead of doing that probing. > > One question I have though... What happens, if a start up script (ini > > script) run in qemu linux-user changes /proc/sys/vm/mmap_min_addr from 0 > > to say 65536? Can this ever work, without later memory allocs with > > mmap() failing? > > If I understood you correctly, it's one more reason for new > mmap_find_vma(). I guess, it should work fine, but I haven't tested this > case. That's generally a different problem. Linux applications tend to be mapped at a fixed address (typically 0x8000 for ARM) If your host system has randomly decided to disallow this then you've much bigger problems.. Paul