From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1Nwi9Y-0000aF-5Y
	for qemu-devel@nongnu.org; Tue, 30 Mar 2010 16:35:12 -0400
Received: from [140.186.70.92] (port=42639 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Nwi9W-0000YC-NH
	for qemu-devel@nongnu.org; Tue, 30 Mar 2010 16:35:11 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <rth@twiddle.net>) id 1Nwi7h-000508-HV
	for qemu-devel@nongnu.org; Tue, 30 Mar 2010 16:33:18 -0400
Received: from are.twiddle.net ([75.149.56.221]:59038)
	by eggs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <rth@twiddle.net>) id 1Nwi7h-000500-B3
	for qemu-devel@nongnu.org; Tue, 30 Mar 2010 16:33:17 -0400
Message-ID: <4BB2600B.90002@twiddle.net>
Date: Tue, 30 Mar 2010 13:33:15 -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>
	<201003302009.o2UK9lAv002282@triton8.kn-bremen.de>
In-Reply-To: <201003302009.o2UK9lAv002282@triton8.kn-bremen.de>
Content-Type: text/plain; charset=UTF-8
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, Toni <tonygio04@gmail.com>, qemu-devel@nongnu.org, Andreas Tobler <andreast@fgznet.ch>

On 03/30/2010 01:09 PM, Juergen Lock wrote:
> Oh sorry if that was not clear, things go into swap if I _replace_ the
> endaddr ~0ul (which caused the assert) with the max value the assert
> still tolerates i.e.
> 	((abi_ulong)1 << L1_MAP_ADDR_SPACE_BITS) - 1
> which in this case seems to be 0x7fffffffffff:

Yes, I got that.  And I see from ...

> #3  0x0000000060012731 in page_set_flags (start=140737488224256, 
>     end=18446744073709551615, flags=32)

... here that the range we're reserving is

  0x7ffffffe0000 ... 0x7fffffffffff

which is a mere 128k range.  Which ought to allocate no more than
a single leaf page table (and thus N-1 pages for the N-level table).

Which doesn't answer the question of why you'd wind up running out
of memory.


r~