From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55576) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zpfjr-0000fB-Pt for qemu-devel@nongnu.org; Fri, 23 Oct 2015 13:02:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zpfjq-00073I-Df for qemu-devel@nongnu.org; Fri, 23 Oct 2015 13:02:47 -0400 Received: from mx1.redhat.com ([209.132.183.28]:49871) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zpfjq-000731-9b for qemu-devel@nongnu.org; Fri, 23 Oct 2015 13:02:46 -0400 Date: Fri, 23 Oct 2015 18:02:41 +0100 From: "Dr. David Alan Gilbert" Message-ID: <20151023170240.GG2711@work-vm> References: <8737x4p8l9.fsf@fimbulvetr.bsc.es> <87si54i2w4.fsf@blackfin.pond.sub.org> <87y4ev81z9.fsf@fimbulvetr.bsc.es> <20151023160138.GJ5977@stefanha-x1.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20151023160138.GJ5977@stefanha-x1.localdomain> 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 (stefanha@gmail.com) wrote: > On Thu, Oct 22, 2015 at 03:30:34PM +0200, Llu=EDs Vilanova wrote: > > Markus Armbruster writes: > >=20 > > > Llu=EDs Vilanova writes: > > [...] > > >> So, is there any agreement on what should be used? If so, could th= at 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= the text. > >=20 > > Cheers, > > Lluis > >=20 > >=20 > > 7. Error reporting >=20 > 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. >=20 > Denial of service cases: >=20 > 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. >=20 > 2. If nested virtualization is used, it's possible that a nested guest > can kill its parent, and thereby also kill its sibling VMs. >=20 > 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. >=20 > Emulated hardware should behave the same way that physical hardware > behaves. This may mean that the device becomes non-operational (ignore= s > or fails new requests) until the next hard or soft reset. I'd add that if the QEMU detects that the guest has done something really stupid and that the device is now dead until reset, then it should output something diagnostic into the logs; otherwise everyone just blames qemu and says it stopped (and I mean log, not trace - I want to see this in the type of thing a users sends so that we have some idea where to look immediately). Dave >=20 -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK