From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47993) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a70HV-0004aN-EK for qemu-devel@nongnu.org; Thu, 10 Dec 2015 07:25:14 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a70HQ-0006qp-NM for qemu-devel@nongnu.org; Thu, 10 Dec 2015 07:25:09 -0500 Received: from mx1.redhat.com ([209.132.183.28]:46830) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a70HQ-0006qN-Il for qemu-devel@nongnu.org; Thu, 10 Dec 2015 07:25:04 -0500 From: Markus Armbruster References: <87a8pl9hmt.fsf@blackfin.pond.sub.org> <20151208141938.GB2593@work-vm> <87io480y0n.fsf@blackfin.pond.sub.org> <566827FC.4080701@redhat.com> <87a8piimvi.fsf@blackfin.pond.sub.org> <56696164.8000009@redhat.com> Date: Thu, 10 Dec 2015 13:25:00 +0100 In-Reply-To: <56696164.8000009@redhat.com> (Paolo Bonzini's message of "Thu, 10 Dec 2015 12:26:28 +0100") Message-ID: <87io46fq3n.fsf@blackfin.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] Error handling in realize() methods List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: qemu-devel@nongnu.org, Peter Maydell , Peter Crosthwaite , "Dr. David Alan Gilbert" , Andreas =?utf-8?Q?F=C3=A4rber?= Paolo Bonzini writes: > On 10/12/2015 12:06, Markus Armbruster wrote: >> Paolo Bonzini writes: >> >>> On 09/12/2015 10:30, Markus Armbruster wrote: >>>> My current working assumption is that passing &error_fatal to >>>> memory_region_init_ram() & friends is okay even in realize() methods and >>>> their supporting code, except when the allocation can be large. >>> >>> I suspect a lot of memory_region_init_ram()s could be considered >>> potentially large (at least in the 16-64 megabytes range). Propagation >>> of memory_region_init_ram() failures is easy enough, thanks to Error**, >>> that we should just do it. >> >> Propagating an out-of-memory error right in realize() is easy. What's >> not so easy is making realize() fail cleanly (all side effects undone; >> we get that wrong in many places), and finding and propagating >> out-of-memory errors hiding deeper in the call tree. > > grep is your friend. We're talking of a subset of these: [...] Yes, finding just the guest memory allocations isn't hard. But making them fail cleanly is, judging from the code that gets it wrong. [...]