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] Xen 4.0.1 "xc_map_foreign_batch: mmap failed: Cannot all

To: <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Xen 4.0.1 "xc_map_foreign_batch: mmap failed: Cannot allocate memory"
From: "Charles Arnold" <carnold@xxxxxxxxxx>
Date: Wed, 05 Jan 2011 10:17:35 -0700
Cc: stefano.stabellini@xxxxxxxxxxxxx
Delivery-date: Wed, 05 Jan 2011 09:18:26 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <alpine.DEB.2.00.1101051422360.2390@kaball-desktop>
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: <C9302D00.D25D%keir@xxxxxxx> <alpine.DEB.2.00.1101051422360.2390@kaball-desktop>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> On 1/5/2011 at 07:37 AM, in message
<alpine.DEB.2.00.1101051422360.2390@kaball-desktop>, Stefano Stabellini
<stefano.stabellini@xxxxxxxxxxxxx> wrote: 
> On Thu, 16 Dec 2010, Keir Fraser wrote:
>> On 16/12/2010 20:44, "Charles Arnold" <carnold@xxxxxxxxxx> wrote:
>> >>> On 12/16/2010 at 01:33 PM, in message <C9302813.2966F%keir@xxxxxxx>, Keir
>> > Fraser <keir@xxxxxxx> wrote:
>> >> On 16/12/2010 19:23, "Charles Arnold" <carnold@xxxxxxxxxx> wrote:
>> >> 
>> >>> The bug is that qemu-dm seems to make the assumption that it can mmap 
>> >>> from
>> >>> dom0 all the memory with which the guest has been defined instead of the
>> >>> memory
>> >>> that is actually available on the host.
>> >> 
>> >> 32-bit dom0? Hm, I thought the qemu mapcache was supposed to limit the 
>> >> total
>> >> amount of guest memory mapped at one time, for a 32-bit qemu. For 64-bit
>> >> qemu I wouldn't expect to find a limit as low as 3.25G.
>> > 
>> > Sorry, I should have specified that it is a 64 bit dom0 / hypervisor.
>> Okay, well I'm not sure what limit qemu-dm is hitting then. Mapping 3.25G of
>> guest memory will only require a few megabytes of pagetables for the qemu
>> process in dom0. Perhaps there is a ulimit or something set on the qemu
>> process?
>> If we can work out and detect this limit, perhaps 64-bit qemu-dm could have
>> a mapping cache similar to 32-bit qemu-dm, limited to some fraction of the
>> detected mapping limit. And/or, on mapping failure, we could reclaim
>> resources by simply zapping the existing cached mappings. Seems there's a
>> few options. I don't really maintain qemu-dm myself -- you might get some
>> help from Ian Jackson, Stefano, or Anthony Perard if you need more advice.
> The mapcache size limit should be 64GB on a 64bit qemu-dm.
> Any interesting error messages in the qemu logs?

No, just the usual mmap error.  See the attached logs.

As a reminder, the following conditions exist to duplicate the problem.
Host: x86_64 sles11sp1.  Boot with dom0_mem=2048M, set (enable-dom0-ballooning 
no) in xend-config.sxp
Hypervisor: x86_64 Xen 4.0.1
Guests: win2k3 (32bit) and win2k8r2 (64bit)
The win2k8r2 guest uses robocopy to copy a 10 Gig file from the win2k3 guest.  
It copied about 23.2% before failing. 

Attachment: qemu-dm-win-2k8r2.log
Description: Binary data

Attachment: qemu-dm-win2k3.log
Description: Binary data

Xen-devel mailing list