From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: Xen-unstable panic: FATAL PAGE FAULT Date: Tue, 31 Aug 2010 17:35:28 +0100 Message-ID: References: <4C7D484B0200007800013415@vpn.id2.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4C7D484B0200007800013415@vpn.id2.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jan Beulich Cc: MaoXiaoyun , xen devel List-Id: xen-devel@lists.xenproject.org On 31/08/2010 17:22, "Jan Beulich" wrote: >> Where is even that constraint ensured in the code? I can't see it (I would >> have assumed that pfn_pdx_hole_setup() would be ensuring it). > > That's somewhat implicit: srat_parse_regions() gets passed an > address that is at least BOOTSTRAP_DIRECTMAP_END (i.e. 4G). > Thus srat_parse_regions() starts off with a mask with the lower > 32 bits all set (only more bits can get set subsequently). Thus > the earliest zero bit pfn_pdx_hole_setup() can find is bit 20 > (due to the >> PAGE_SHIFT in the invocation). Consequently > the smallest chunk where arithmetic is valid really is 4Gb, not > 256Mb as I first wrote. Well, that's a bit too implicit for me. How about we initialise 'j' to MAX_ORDER in pfn_pdx_hole_setup() with a comment about supporting page_info pointer arithmetic within allocatable multi-page regions? Something like the appended (but with a code comment)? -- Keir --- a/xen/arch/x86/x86_64/mm.c Mon Aug 30 14:59:12 2010 +0100 +++ b/xen/arch/x86/x86_64/mm.c Tue Aug 31 17:34:34 2010 +0100 @@ -165,7 +165,8 @@ { unsigned int i, j, bottom_shift, hole_shift; - for ( hole_shift = bottom_shift = j = 0; ; ) + hole_shift = bottom_shift = 0; + for ( j = MAX_ORDER-1; ; ) { i = find_next_zero_bit(&mask, BITS_PER_LONG, j); j = find_next_bit(&mask, BITS_PER_LONG, i);