This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] BUG: unable to handle kernel paging request - balloon_in

To: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Subject: Re: [Xen-devel] BUG: unable to handle kernel paging request - balloon_init - xen-4.1.0 -
From: Scott Garron <xen-devel@xxxxxxxxxxxxxxxxxx>
Date: Thu, 28 Apr 2011 20:15:19 -0400
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 28 Apr 2011 17:16:24 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20110428183019.GA9852@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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4DB60C04.6050802@xxxxxxxxxxxxxxxxxx> <20110426031545.GB20779@xxxxxxxxxxxx> <4DB6522A.9000304@xxxxxxxxxxxxxxxxxx> <20110427200937.GA19853@xxxxxxxxxxxx> <4DB8AAA6.4050808@xxxxxxxxxxxxxxxxxx> <20110428183019.GA9852@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20101226 Icedove/3.0.11
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.


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


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

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

     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

Xen-devel mailing list