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:01:07 +0100 Message-ID: References: <4C7D36CB0200007800013394@vpn.id2.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4C7D36CB0200007800013394@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 16:07, "Jan Beulich" wrote: >>>> 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) > > Any range of struct page_info-s that crosses a 2Mb boundary is > unsafe to make assumptions upon 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). -- Keir > (with 32-byte struct page_info > that means 256Mb of memory, but if struct page_info grows that > range might shrink). If that limit is too low, we might need to > enforce a lower limit on the bit positions on which compression > may be done (possibly at the price of doing less compression).