From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Scott Parish" Subject: Re: bitopts functions overflowing page boundarys Date: Sat, 28 May 2005 09:04:22 +0000 Message-ID: <20050528090422.GB9951@us.ibm.com> References: <20050528044320.GA9951@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: 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: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On Sat, May 28, 2005 at 10:01:27AM +0100, Keir Fraser wrote: > > On 28 May 2005, at 05:43, Scott Parish wrote: > > >u.inuse.type_info is at the end of the pfn_info structure, and is > >u32 for both x86_32 and x86_64--in this location it can also be the > >last 32 bits of a page. > > > >several functions use bitopts.h functions to manipulate this member, > >and > >on x86_64 these functions use u64 instructions, which will overflow the > >page boundary, and possibly the end of memory as we see here: > > You really see this in practise? I'm very surprised. The memory map > would have to be just big enough that the last pfn_info structure falls > at the end of an aligned 2MB boundary. If you reduce max_page by 1, > does the problem disappear? Here's the memory map for one of the boxes we're seeing this on: (XEN) Physical RAM map: (XEN) 0000000000000000 - 000000000009dc00 (usable) (XEN) 000000000009dc00 - 00000000000a0000 (reserved) (XEN) 00000000000d0000 - 0000000000100000 (reserved) (XEN) 0000000000100000 - 00000000dff60000 (usable) (XEN) 00000000dff60000 - 00000000dff72000 (ACPI data) (XEN) 00000000dff72000 - 00000000dff80000 (ACPI NVS) (XEN) 00000000dff80000 - 00000000e0000000 (reserved) (XEN) 00000000fec00000 - 00000000fec00400 (reserved) (XEN) 00000000fee00000 - 00000000fee01000 (reserved) (XEN) 00000000fff80000 - 0000000100000000 (reserved) (XEN) 0000000100000000 - 0000000180000000 (usable) No problem when dom0_mem is less then 2048K; at exactly 2048 we hit the next sized "order" which can't be fulfilled from the 0x100-0xdff60 range. All initial allocation for dom0 that i've seen that fall in the "usable" above the hole have the problem i described. Setting, max_page = init_e820(e820_raw, &e820_raw_nr) - 1; seems to unravel a number of things. shall i preceed to figure out what all, or is such still needed? sRp -- Scott Parish Signed-off-by: srparish@us.ibm.com