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-unstable panic: FATAL PAGE FAULT

To: Jan Beulich <JBeulich@xxxxxxxxxx>
Subject: Re: [Xen-devel] Xen-unstable panic: FATAL PAGE FAULT
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Tue, 31 Aug 2010 17:35:28 +0100
Cc: MaoXiaoyun <tinnycloud@xxxxxxxxxxx>, xen devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 31 Aug 2010 09:36:37 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4C7D484B0200007800013415@xxxxxxxxxxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: ActJKKQbT7gwtw5tTbS5vPHoCRxZmQAAeD3a
Thread-topic: [Xen-devel] Xen-unstable panic: FATAL PAGE FAULT
User-agent: Microsoft-Entourage/12.26.0.100708
On 31/08/2010 17:22, "Jan Beulich" <JBeulich@xxxxxxxxxx> 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);



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