From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1NK2m4-0007Q6-Oi
	for qemu-devel@nongnu.org; Sun, 13 Dec 2009 23:43:08 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1NK2m3-0007Pu-DD
	for qemu-devel@nongnu.org; Sun, 13 Dec 2009 23:43:07 -0500
Received: from [199.232.76.173] (port=49191 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1NK2m3-0007Pr-7f
	for qemu-devel@nongnu.org; Sun, 13 Dec 2009 23:43:07 -0500
Received: from are.twiddle.net ([75.149.56.221]:48312)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <rth@twiddle.net>) id 1NK2m2-0003QN-Q2
	for qemu-devel@nongnu.org; Sun, 13 Dec 2009 23:43:06 -0500
Received: from stone.twiddle.home (stone.twiddle.home [172.31.0.16])
	by are.twiddle.net (Postfix) with ESMTPSA id 792FA304
	for <qemu-devel@nongnu.org>; Sun, 13 Dec 2009 20:43:05 -0800 (PST)
Message-ID: <4B25C259.6080202@twiddle.net>
Date: Sun, 13 Dec 2009 20:43:05 -0800
From: Richard Henderson <rth@twiddle.net>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [patch] linux-user: problem with mmap_find_vma
References: <4B25BBB8.5070807@twiddle.net>
In-Reply-To: <4B25BBB8.5070807@twiddle.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org

On 12/13/2009 08:14 PM, Richard Henderson wrote:
> With host x86_64 target alpha, a trivial recompile started producing
> "MMU faults". Eventually, I determined that adding "-B 0x100000000" was
> enough to produce the fault with the original working executable. I
> expect, but have not verified, that a similar failure can be elicited
> with any 64-bit host and any target using such a large explicit base.
>
> The cause is that the default address used by mmap_find_vma may not be
> inside the area defined for use by the guest by GUEST_BASE. Certainly
> this patch fixes the failure I was seeing.
>
> I cannot see though all the macro ugliness to understand what happens
> when GUEST_BASE is not in use to know what needs happening there. Please
> feel free to edit the ??? comment to match reality.

... Well, while I do think this patch is still a good idea,
since one hardly likes to see things like

   start_stack 0xffffffff04012000

it seems to simply have moved the MMU data fault around; it's back with 
the rest of the patch set applied.  :-(


r~