From mboxrd@z Thu Jan  1 00:00:00 1970
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: Xen dom0 crash: "d0:v0: unhandled page	fault
	(ec=0000)"
Date: Mon, 1 Nov 2010 13:39:40 -0400
Message-ID: <20101101173940.GA6068@dumpdata.com>
References: <19629.39326.337589.71778@wylie.me.uk>
	<1287498599.12843.2111.camel@qabil.uk.xensource.com>
	<4CBDB229.3030501@infinitumb.de>
	<1287503143.12843.2191.camel@qabil.uk.xensource.com>
	<4CBE2A43.70200@hfp.de>
	<1287564863.12843.4194.camel@qabil.uk.xensource.com>
	<1288367063.23619.51.camel@qabil.uk.xensource.com>
	<20101029161553.GA27408@dumpdata.com> <4CCEC2A8.6040103@goop.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-path: <xen-devel-bounces@lists.xensource.com>
Content-Disposition: inline
In-Reply-To: <4CCEC2A8.6040103@goop.org>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com
To: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: "Alan J. Wylie" <NDA5OWUy@wylie.me.uk>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Gianni Tedesco <gianni.tedesco@citrix.com>, Stefan Kuhne <stefan.kuhne@gmx.net>, sven <ml@infinitumb.de>, Andreas Kinzler <ml-xen-devel@hfp.de>
List-Id: xen-devel@lists.xenproject.org

> >> http://pastebin.com/3m0DpDdW - 2.6.32.24-gd0054d6-dirty - broken
.. snip..
> The way is this is supposed to work is:
> 
>    1. Xen gives the domain N pages
>    2. There's an E820 which describes M pages (M > N)
>    3. The kernel traverses the existing E820 and finds holes and adds
>       the memory to a new E820_RAM region beyond M
>    4. Set up P2M for pages up to N
>    5. When the kernel maps all "RAM", the region from N-M is not
>       present, and has no valid P2M mapping; in that case, xen_make_pte
>       will return a non-present pte.

Right, and somehow his machine/kernel is not doing this. His 'N' ends up being 'M' so
the region N-M is added to the "RAM", and xen_make_pte I _think_ returns a non-present pte
(or maybe it does present a present pte?) In the previous kernel (2.6.32.18), it
does exactly what you described.

Take a look at his http://pastebin.com/3m0DpDdW

[    0.000000]  Xen: 0000000000000000 - 000000000009e000 (usable)
[    0.000000]  Xen: 0000000000100000 - 000000002f000000 (usable)
[    0.000000]  Xen: 00000000bf699000 - 00000000bf6af000 (reserved)
[    0.000000]  Xen: 00000000bf6af000 - 00000000bf6ce000 (ACPI data)
[    0.000000]  Xen: 00000000bf6ce000 - 00000000c0000000 (reserved)
[    0.000000]  Xen: 00000000e0000000 - 00000000f0000000 (reserved)
[    0.000000]  Xen: 00000000fe000000 - 0000000100000000 (reserved)
[    0.000000]  Xen: 0000000240000000 - 00000002d0699000 (usable)

He passes in dom0_mem=752M flag, so it should stop right at pfn 2f0000,
but it continues on with 0x2d0699.
> 
> The important part of making XEN EXTRA E820_RAM is that the kernel will
> allocate page structures for them, even if the pages are absent.  Making
> it RESERVED will suppress that and make the exercise pointless.

<nods> Happens in 2.6.32.18, but not 2.6.32.24 with his kernel. That region ends
up being allocated.