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: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Subject: Re: [Xen-devel] Xen dom0 crash: "d0:v0: unhandled page fault (ec=0000)"
From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Mon, 01 Nov 2010 13:46:01 -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:46:54 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20101101173940.GA6068@xxxxxxxxxxxx>
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> <20101101173940.GA6068@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.9) Gecko/20100921 Fedora/3.1.4-1.fc13 Lightning/1.0b3pre Thunderbird/3.1.4
 On 11/01/2010 01:39 PM, Konrad Rzeszutek Wilk wrote:
>>>> 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.

I doubt it.  On older kernels it would just truncate the max E820
address to N, not even respecting any holes, so N=M and all memory is
properly mapped.

> 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.

Yes.  The current behaviour is that dom0_mem sets N, but the host E820
sets M, so there's the possibility of ballooning dom0 up to full memory
size (or at least up to 10N).

If you set mem= on the kernel command line, you can trunate M.

>> 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.

Hm.  Not sure about that.

    J


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