From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:58245) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SeS4i-0005rT-7p for qemu-devel@nongnu.org; Tue, 12 Jun 2012 10:28:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SeS4g-0003R4-A9 for qemu-devel@nongnu.org; Tue, 12 Jun 2012 10:28:03 -0400 Received: from mail-yx0-f173.google.com ([209.85.213.173]:35562) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SeS4g-0003QF-3e for qemu-devel@nongnu.org; Tue, 12 Jun 2012 10:28:02 -0400 Received: by yenm4 with SMTP id m4so3903438yen.4 for ; Tue, 12 Jun 2012 07:28:00 -0700 (PDT) Sender: Richard Henderson Message-ID: <4FD751EA.2070501@twiddle.net> Date: Tue, 12 Jun 2012 07:27:54 -0700 From: Richard Henderson MIME-Version: 1.0 References: <1339107871-4487-1-git-send-email-rth@twiddle.net> <1339107871-4487-3-git-send-email-rth@twiddle.net> <4FD74E32.7000705@suse.de> In-Reply-To: <4FD74E32.7000705@suse.de> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH 2/9] alpha-linux-user: Work around hosted mmap allocation problems List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?ISO-8859-15?Q?Andreas_F=E4rber?= Cc: Peter Maydell , Alexander Graf , Riku Voipio , Paul Brook , qemu-devel@nongnu.org On 2012-06-12 07:12, Andreas Färber wrote: > This looks fishy to me... why should the kernel use a bigger address > space than hardware? For arm on x86_64 such a workaround was not > necessary iirc. I can tell you what I observe. That with a certain sequence of allocations the x86_64 kernel will quit accepting an address "near" (1<<38) as a hint for where to allocate memory and begin returning an addresses near (1<<48). Further, the logic in find_mmap_vma tries about 5 times (with different hints) to get a target-page-aligned address at a lower address, all of which fail: the kernel continues to return the (1<<48) address. At which point one wonders why we should keep refusing the (1<<48) address when the target is in fact 64-bit capable. I believe the host vs target page size difference plays a part in this, which is why you wouldn't see this on arm. All of the other targets with page size larger than 4k are 64 bit, and set TARGET_VIRT_ADDR_SPACE_BITS to 64. So Alpha was unique in being an 8k page size with T_B_A_S_B < 48, and so probably unique in being able to tickle this problem. r~