From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: Xen-unstable panic: FATAL PAGE FAULT Date: Tue, 31 Aug 2010 17:22:03 +0100 Message-ID: <4C7D484B0200007800013415@vpn.id2.novell.com> References: <4C7D36CB0200007800013394@vpn.id2.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: MaoXiaoyun , xen devel List-Id: xen-devel@lists.xenproject.org >>> On 31.08.10 at 18:01, Keir Fraser wrote: > On 31/08/2010 16:07, "Jan Beulich" wrote: >=20 >>>>> On 31.08.10 at 16:49, Keir Fraser wrote: >>> I'm cc'ing Jan to see what we can get away with in doing arithmetic on >>> page_info pointers. What's the guaranteed smallest aligned contiguous = ranges >>> of mfn in the frame_table now, Jan? (i.e., ranges in which adjacent >>> page_info structs relate to adjacent MFNs) >>=20 >> Any range of struct page_info-s that crosses a 2Mb boundary is >> unsafe to make assumptions upon >=20 > 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. Jan