From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38832) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZpgF1-0007bQ-Nj for qemu-devel@nongnu.org; Fri, 23 Oct 2015 13:35:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZpgEy-0001WS-HU for qemu-devel@nongnu.org; Fri, 23 Oct 2015 13:34:59 -0400 Received: from roura.ac.upc.edu ([147.83.33.10]:43294 helo=roura.ac.upc.es) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZpgEy-0001Vl-74 for qemu-devel@nongnu.org; Fri, 23 Oct 2015 13:34:56 -0400 From: =?utf-8?Q?Llu=C3=ADs_Vilanova?= References: <8737x4p8l9.fsf@fimbulvetr.bsc.es> <87si54i2w4.fsf@blackfin.pond.sub.org> <87y4ev81z9.fsf@fimbulvetr.bsc.es> <20151023160138.GJ5977@stefanha-x1.localdomain> Date: Fri, 23 Oct 2015 19:34:50 +0200 In-Reply-To: <20151023160138.GJ5977@stefanha-x1.localdomain> (Stefan Hajnoczi's message of "Fri, 23 Oct 2015 17:01:38 +0100") Message-ID: <87lhattrnp.fsf@fimbulvetr.bsc.es> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] Coding style for errors List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Peter Maydell , Markus Armbruster , qemu-devel@nongnu.org Stefan Hajnoczi writes: > On Thu, Oct 22, 2015 at 03:30:34PM +0200, Llu=C3=ADs Vilanova wrote: >> Markus Armbruster writes: >>=20 >> > Llu=C3=ADs Vilanova writes: >> [...] >> >> So, is there any agreement on what should be used? If so, could that = please be >> >> added to CODING_STYLE? >>=20 >> > I think HACKING would be a better fit. >>=20 >> What about this? (at the end of HACKING) Feel free to add references to = other >> functions you think are important. I'll send a patch once we agree on th= e text. >>=20 >> Cheers, >> Lluis >>=20 >>=20 >> 7. Error reporting > Guest-triggerable errors should not terminate QEMU. There are plently > of examples where this is violated today but there are good reasons to > stop doing it. > Denial of service cases: > 1. If a guest userspace application is somehow able to trigger a QEMU > abort, then an unprivileged guest application is able to bring down > the whole VM. > 2. If nested virtualization is used, it's possible that a nested guest > can kill its parent, and thereby also kill its sibling VMs. > 3. abort(3) is heavyweight if crash reporting/coredumps are enabled. A > broken/malicious guest that keeps triggering abort(3) can be a big > nuisance that consumes memory, disk, and CPU resources. > Emulated hardware should behave the same way that physical hardware > behaves. This may mean that the device becomes non-operational (ignores > or fails new requests) until the next hard or soft reset. I'm not sure how this should be translated into the form of error-reporting guidelines. Thanks, Lluis --=20 "And it's much the same thing with knowledge, for whenever you learn something new, the whole world becomes that much richer." -- The Princess of Pure Reason, as told by Norton Juster in The Phantom Tollbooth