From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50332) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z5GEe-0001ts-Ec for qemu-devel@nongnu.org; Wed, 17 Jun 2015 12:30:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z5GEd-0007de-JW for qemu-devel@nongnu.org; Wed, 17 Jun 2015 12:30:44 -0400 Received: from mx1.redhat.com ([209.132.183.28]:34200) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z5GEd-0007ce-DN for qemu-devel@nongnu.org; Wed, 17 Jun 2015 12:30:43 -0400 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id E347F2F1466 for ; Wed, 17 Jun 2015 16:30:42 +0000 (UTC) Date: Wed, 17 Jun 2015 18:30:40 +0200 From: "Michael S. Tsirkin" Message-ID: <20150617183015-mutt-send-email-mst@redhat.com> References: <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> <55819D12.7060203@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55819D12.7060203@redhat.com> 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: Paolo Bonzini Cc: Igor Mammedov , qemu-devel@nongnu.org On Wed, Jun 17, 2015 at 06:15:14PM +0200, Paolo Bonzini wrote: > > > 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 So let's ignore it for now, we always crash if e.g. close fails, too.