From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1NwhKI-0005Il-0N
	for qemu-devel@nongnu.org; Tue, 30 Mar 2010 15:42:14 -0400
Received: from [140.186.70.92] (port=59305 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1NwhKC-0005Ic-J6
	for qemu-devel@nongnu.org; Tue, 30 Mar 2010 15:42:13 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <rth@twiddle.net>) id 1NwhKA-0007WE-2c
	for qemu-devel@nongnu.org; Tue, 30 Mar 2010 15:42:08 -0400
Received: from are.twiddle.net ([75.149.56.221]:47202)
	by eggs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <rth@twiddle.net>) id 1NwhK9-0007W4-Q4
	for qemu-devel@nongnu.org; Tue, 30 Mar 2010 15:42:05 -0400
Message-ID: <4BB2540B.90704@twiddle.net>
Date: Tue, 30 Mar 2010 12:42:03 -0700
From: Richard Henderson <rth@twiddle.net>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] qemu git head 20100323 on FreeBSD - qemu-devel	port
	update for testing
References: <20100325204423.GA46954@triton8.kn-bremen.de>	<f43fc5581003301104x77c0e527m871b035a7364bd5b@mail.gmail.com>
	<20100330191629.GA95521@triton8.kn-bremen.de>
In-Reply-To: <20100330191629.GA95521@triton8.kn-bremen.de>
Content-Type: text/plain; charset=ISO-8859-1
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: Juergen Lock <nox@jelal.kn-bremen.de>
Cc: Blue Swirl <blauwirbel@gmail.com>, freebsd-emulation@freebsd.org, Andreas Tobler <andreast@fgznet.ch>, qemu-devel@nongnu.org, Toni <tonygio04@gmail.com>

On 03/30/2010 12:16 PM, Juergen Lock wrote:
>  I first tried to replace the endaddr in the !h2g_valid(endaddr) case with
> 	((abi_ulong)1 << L1_MAP_ADDR_SPACE_BITS) - 1
> if TARGET_ABI_BITS > L1_MAP_ADDR_SPACE_BITS (which comes from the condition
> of the assert in page_set_flags() that was triggered on the ~0ul value),
> but that caused the qemu process to grow into swap and made the box
> usuable when that code was reached and I had to kill qemu.  (The box has
> 8 GB RAM.)  And so I thought just leaving that page range unprotected
> if only the start address is valid was the lesser evil...

What's are the real arguments to the page_set_flags that causes things
to go into swap?  I can't imagine the range really being so large that
it causes massive allocation within that function...


r~