Re: BUG: unable to handle kernel paging request - balloon_init - xen-4.1.0 - 2.6.32.39

[Scott Garron <xen-devel@sce.pridelands.org>]

On 04/28/2011 02:30 PM, Konrad Rzeszutek Wilk wrote:
> And you say it boots fine under DomU - so there is some P2M, E820
> funkiness happening here I think. Had you tried booting the kernel
> as Dom0 with different sizes of dom0_mem ("dom0_mem=max:2GB?") Or
> without the dom0_mem parameter at all?

 From my first message to the list in this thread:

    "I've tried booting with no dom0_mem option just to see if
     that made any difference."

The same crash happened with or without the dom0_mem parameter.  After
trying "dom0_mem=max:2048MB" just now, I get the same crash.

> What is your CONFIG_XEN_MAX_DOMAIN_MEMORY set to?

      It's currently set to 128.  The kernel config I'm using is at

http://www.pridelands.org/~simba/xen-debug/hailstorm-kernelconfig.txt

      Here's what has me scratching my head, though...  This bytecode
instruction:

0xffffffff819a8aca <balloon_init+491>:  imul   $0x38,%rdx,%rcx

      If I use gdb to point me to the C code for that instruction, it
gives me:

page = pfn_to_page(pfn);

... from within the for() loop in question.  Expanding the macro
"pfn_to_page(pfn)", I get:

(((struct page *)(0xffffea0000000000UL)) + (pfn))

      So, the preprocessed C code should look like:

page = (((struct page *)(0xffffea0000000000UL)) + (pfn));

      Why would an addition operation in C translate to a multiplication
instruction in the bytecode?  Moreover, where does multiplying by 0x38
come from?  It seems to me that if pfn is 0x100000, and it gets added to
0xffffea0000000000, the end result would be 0xffffea0000100000.  The
pr_info() that I added shows that "page" is equal to 0xffffea0003800000,
indicating that it multiplied pfn by 0x38 before adding it to
0xffffea0000000000 instead of simply adding it.

      Because the kernel configuration option "CONFIG_SPARSEMEM_VMEMMAP"
mentioned pfn_to_page(pfn), one of the things I tried was unsetting it
but ended up with the same results (except that "page" was
0x0000000003800000).

      Then, I suspected a compiler problem, so I tried recompiling with
gcc 4.3 instead of 4.5.  Same results.

      Just for kicks, I tried hexediting balloon.o and changing that
instruction to "imul   $0x1,%rdx,%rcx" (since multiplying by 1 will
essentially nullify the instruction), but the end result was still the
same crash, even though the value for "page" ended up being
0x0000000000100000.  It would seem that my suspicion on that instruction
was incorrect, but I'm still having trouble wrapping my mind around why
0x38 is even there.

-- 
Scott Garron