Re: bitopts functions overflowing page boundarys

["Scott Parish" <srparish@us.ibm.com>]

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