From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50044) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a3OFc-0007LN-Pw for qemu-devel@nongnu.org; Mon, 30 Nov 2015 08:12:17 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a3OFY-0004kr-7t for qemu-devel@nongnu.org; Mon, 30 Nov 2015 08:12:16 -0500 Received: from mx1.redhat.com ([209.132.183.28]:37183) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a3OFX-0004kd-OY for qemu-devel@nongnu.org; Mon, 30 Nov 2015 08:12:12 -0500 Date: Mon, 30 Nov 2015 15:12:08 +0200 From: "Michael S. Tsirkin" Message-ID: <20151130151039-mutt-send-email-mst@redhat.com> References: <20151130105044.12269.21261.stgit@bahia.huguette.org> <565C2AB5.7050008@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <565C2AB5.7050008@redhat.com> Subject: Re: [Qemu-devel] [PATCH] mmap-alloc: use same backend for all mappings List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: qemu-devel@nongnu.org, Greg Kurz On Mon, Nov 30, 2015 at 11:53:41AM +0100, Paolo Bonzini wrote: > > > On 30/11/2015 11:51, Greg Kurz wrote: > > Since commit 8561c9244ddf1122d "exec: allocate PROT_NONE pages on top of RAM", > > it is no longer possible to back guest RAM with hugepages on ppc64 hosts: > > > > mmap(NULL, 285212672, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x3fff57000000 > > mmap(0x3fff57000000, 268435456, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 19, 0) = -1 EBUSY (Device or resource busy) > > > > This is due to a limitation on ppc64 that requires MAP_FIXED mappings to have > > the same page size as other mappings already present in the same "slice" of > > virtual address space (Cc'ing Ben for details). This is exactly what happens > > when calling mmap() above: first one uses native host page size (64k) and > > second one uses huge page size (16M). > > > > To be sure we always have the same page size, let's use the same backend for > > both calls to mmap(): this is enough to fix the ppc64 issue. > > > > This has no effect on RAM based mappings. > > > > Signed-off-by: Greg Kurz > > --- > > > > This is a bug fix for 2.5 > > > > util/mmap-alloc.c | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/util/mmap-alloc.c b/util/mmap-alloc.c > > index c37acbe58ede..0ff221dd94f4 100644 > > --- a/util/mmap-alloc.c > > +++ b/util/mmap-alloc.c > > @@ -21,7 +21,8 @@ void *qemu_ram_mmap(int fd, size_t size, size_t align, bool shared) > > * space, even if size is already aligned. > > */ > > size_t total = size + align; > > - void *ptr = mmap(0, total, PROT_NONE, MAP_ANONYMOUS | MAP_PRIVATE, -1, 0); > > + void *ptr = mmap(0, total, PROT_NONE, > > + (fd == -1 ? MAP_ANONYMOUS : 0) | MAP_PRIVATE, fd, 0); > > size_t offset = QEMU_ALIGN_UP((uintptr_t)ptr, align) - (uintptr_t)ptr; > > void *ptr1; > > > > > > Acked-by: Paolo Bonzini But why does this patch have any effect? I'm worried that extra memory is still allocated with this, even if it's not accessible. If yes, we are better off disabling the protection for ppc. -- MST