Xen 
 
Home About Xen.org Xen Xen Summit Wiki Mailing List Bug Tracker Xen Downloads
 
   
 

xen-devel

Re: [Xen-devel] bitopts functions overflowing page boundarys

To: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] bitopts functions overflowing page boundarys
From: "Scott Parish" <srparish@xxxxxxxxxx>
Date: Sat, 28 May 2005 09:04:22 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Sat, 28 May 2005 09:40:28 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <be86dbb7af4e9fbc0a5bd48764109c85@xxxxxxxxxxxx>
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20050528044320.GA9951@xxxxxxxxxx> <be86dbb7af4e9fbc0a5bd48764109c85@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.4.2.1i
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@xxxxxxxxxx

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