WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Xen dom0 crash: "d0:v0: unhandled page fault (ec=0000)"

To: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: Re: [Xen-devel] Xen dom0 crash: "d0:v0: unhandled page fault (ec=0000)"
From: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Date: Mon, 1 Nov 2010 13:39:40 -0400
Cc: "Alan J. Wylie" <NDA5OWUy@xxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Gianni Tedesco <gianni.tedesco@xxxxxxxxxx>, Stefan Kuhne <stefan.kuhne@xxxxxxx>, sven <ml@xxxxxxxxxxxxx>, Andreas Kinzler <ml-xen-devel@xxxxxx>
Delivery-date: Mon, 01 Nov 2010 10:40:55 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4CCEC2A8.6040103@xxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <19629.39326.337589.71778@xxxxxxxxxxx> <1287498599.12843.2111.camel@xxxxxxxxxxxxxxxxxxxxxx> <4CBDB229.3030501@xxxxxxxxxxxxx> <1287503143.12843.2191.camel@xxxxxxxxxxxxxxxxxxxxxx> <4CBE2A43.70200@xxxxxx> <1287564863.12843.4194.camel@xxxxxxxxxxxxxxxxxxxxxx> <1288367063.23619.51.camel@xxxxxxxxxxxxxxxxxxxxxx> <20101029161553.GA27408@xxxxxxxxxxxx> <4CCEC2A8.6040103@xxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.20 (2009-06-14)
> >> 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.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel