From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39459) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZrTpm-0008NE-NV for qemu-devel@nongnu.org; Wed, 28 Oct 2015 12:44:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZrTpj-0007wn-Bd for qemu-devel@nongnu.org; Wed, 28 Oct 2015 12:44:22 -0400 Received: from mx1.redhat.com ([209.132.183.28]:58195) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZrTpj-0007wf-6B for qemu-devel@nongnu.org; Wed, 28 Oct 2015 12:44:19 -0400 References: <8737x4p8l9.fsf@fimbulvetr.bsc.es> <87si54i2w4.fsf@blackfin.pond.sub.org> <87y4ev81z9.fsf@fimbulvetr.bsc.es> <20151023160138.GJ5977@stefanha-x1.localdomain> <20151023170240.GG2711@work-vm> From: Thomas Huth Message-ID: <5630FB5D.9040003@redhat.com> Date: Wed, 28 Oct 2015 17:44:13 +0100 MIME-Version: 1.0 In-Reply-To: <20151023170240.GG2711@work-vm> 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: "Dr. David Alan Gilbert" , Stefan Hajnoczi Cc: Peter Maydell , Markus Armbruster , qemu-devel@nongnu.org On 23/10/15 19:02, Dr. David Alan Gilbert wrote: > * Stefan Hajnoczi (stefanha@gmail.com) wrote: >> On Thu, Oct 22, 2015 at 03:30:34PM +0200, Llu=C3=ADs Vilanova wrote: >>> Markus Armbruster writes: >>> >>>> Llu=C3=ADs Vilanova writes: >>> [...] >>>>> So, is there any agreement on what should be used? If so, could tha= t please be >>>>> added to CODING_STYLE? >>> >>>> I think HACKING would be a better fit. >>> >>> 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. >>> >>> Cheers, >>> Lluis >>> >>> >>> 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 (ignor= es >> or fails new requests) until the next hard or soft reset. >=20 > I'd add that if the QEMU detects that the guest has done something real= ly > 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). ... and call qemu_system_guest_panicked() so that the management layers can flag the guest accordingly? Thomas