From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Keir Fraser <keir.fraser@eu.citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: Hyp compat_memory_op() and 256 GB PV
Date: Wed, 18 Feb 2009 11:52:22 -0800 [thread overview]
Message-ID: <499C66F6.5070307@oracle.com> (raw)
In-Reply-To: <C5C17600.2D96%keir.fraser@eu.citrix.com>
Keir Fraser wrote:
> On 18/02/2009 03:39, "Mukesh Rathor" <mukesh.rathor@oracle.com> wrote:
>
>> Moving on to 256 GB guest, the hyp is failing the XENMEM_populate_physmap
>> hcall in compat_memory_op(). The problem is size too large for continuation
>> encoding:
>>
>> /* Is size too large for us to encode a continuation? */
>> if ( cmp.rsrv.nr_extents > (UINT_MAX >> MEMOP_EXTENT_SHIFT))
>> return start_extent;
>>
>> for 256 GB : nr_extents == 0x4000000
>>
>> Currently at a loss on this one!
>
> Well, who's making the compat call? Not the guest itself presumably since it
> is 64-bit? So it's probably dom0? But I would think that dom0 would only do
> large amounts of allocation for the new domU in xc_hvm_build.c, and that is
> careful to allocate memory in batches of 8MB at a time.
>
> Basically you need to track down the call site of the failed
> compat_memory_op().
>
> -- Keir
>
Hi Keir,
I see this in domain-builder-ng.log:
elf_xen_addr_calc_check: addresses:
virt_base = 0xffffffff80000000
elf_paddr_offset = 0xffffffff80000000
virt_offset = 0x0
virt_kstart = 0xffffffff80200000
virt_kend = 0xffffffff807014e4
virt_entry = 0xffffffff80200000
xc_dom_parse_elf_kernel: xen-3.0-x86_64: 0xffffffff80200000 ->
0xffffffff807014e4
xc_dom_mem_init: mem 262144 MB, pages 0x4000000 pages, 4k each
xc_dom_mem_init: 0x4000000 pages
xc_dom_boot_mem_init: called
x86_compat: guest xen-3.0-x86_64, address size 64
xc_dom_malloc : 256 MB
xc_dom_boot.c:143: panic: xc_dom_boot_mem_init: can't allocate low
memory for domain
I set a breakpoint in compat_memory_op() and stepping thru it, noticed
it was bailing out at the if statement, and nr_extents was 0x4000000.
This is a PV domain BTW, I guess xc_hvm_build.c wont' be involved. I'll
instrument libxc and debug more... meanwhile I thought I'd post this.
Thanks,
Mukesh
next prev parent reply other threads:[~2009-02-18 19:52 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-18 3:39 Hyp compat_memory_op() and 256 GB PV Mukesh Rathor
2009-02-18 8:23 ` Keir Fraser
2009-02-18 19:52 ` Mukesh Rathor [this message]
2009-02-18 20:54 ` Keir Fraser
2009-03-18 21:50 ` Mukesh Rathor
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=499C66F6.5070307@oracle.com \
--to=mukesh.rathor@oracle.com \
--cc=keir.fraser@eu.citrix.com \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.