From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45302) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z5Fzo-0001HW-Pz for qemu-devel@nongnu.org; Wed, 17 Jun 2015 12:15:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z5Fzi-0003wj-IZ for qemu-devel@nongnu.org; Wed, 17 Jun 2015 12:15:24 -0400 Received: from mx1.redhat.com ([209.132.183.28]:42736) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z5Fzi-0003wB-E9 for qemu-devel@nongnu.org; Wed, 17 Jun 2015 12:15:18 -0400 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 2D15BB7CE0 for ; Wed, 17 Jun 2015 16:15:18 +0000 (UTC) Message-ID: <55819D12.7060203@redhat.com> Date: Wed, 17 Jun 2015 18:15:14 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1433776757-61958-1-git-send-email-imammedo@redhat.com> <1433776757-61958-4-git-send-email-imammedo@redhat.com> <5575B58B.50105@redhat.com> <20150608181314.3ab8fc80@nial.brq.redhat.com> <20150608182206-mutt-send-email-mst@redhat.com> <5575CB9F.4060807@redhat.com> <20150609120855.7e19c588@nial.brq.redhat.com> <55812C48.50607@redhat.com> <20150617170437.057db335@nial.brq.redhat.com> <20150617170704-mutt-send-email-mst@redhat.com> In-Reply-To: <20150617170704-mutt-send-email-mst@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC v2 3/6] memory: support unmapping of MemoryRegion mapped into HVA parent List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" , Igor Mammedov Cc: qemu-devel@nongnu.org On 17/06/2015 17:10, Michael S. Tsirkin wrote: > > Actually memory_region_add_subregion(cannot fail) will continue to casue problems > > in case one of the listeners fails and has no way to propagate error up the stack. > > It could be that vhost_set_memory() or kvm_set_memslots() aren't able to allocate > > memory for replacement table in low memory conditions and without > > way to report back QEMU is left with option to die. > > mmap reserving memory just adds it to a data structure somewhere > within glibc, doesn't it? Looks like it's highly unlikely to fail, > so maybe killing QEMU if it does isn't a big deal. It's in the kernel, but yes, a MAP_NORESERVE mmap is highly unlikely to fail. Paolo