From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:40977)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <lersek@redhat.com>) id 1ZpexN-0001MS-QW
	for qemu-devel@nongnu.org; Fri, 23 Oct 2015 12:12:42 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <lersek@redhat.com>) id 1ZpexK-0007EC-Dv
	for qemu-devel@nongnu.org; Fri, 23 Oct 2015 12:12:41 -0400
Received: from mx1.redhat.com ([209.132.183.28]:56411)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <lersek@redhat.com>) id 1ZpexK-0007E8-8Q
	for qemu-devel@nongnu.org; Fri, 23 Oct 2015 12:12:38 -0400
References: <8737x4p8l9.fsf@fimbulvetr.bsc.es>
	<87si54i2w4.fsf@blackfin.pond.sub.org>
	<87y4ev81z9.fsf@fimbulvetr.bsc.es>
	<20151023160138.GJ5977@stefanha-x1.localdomain>
From: Laszlo Ersek <lersek@redhat.com>
Message-ID: <562A5C72.5040900@redhat.com>
Date: Fri, 23 Oct 2015 18:12:34 +0200
MIME-Version: 1.0
In-Reply-To: <20151023160138.GJ5977@stefanha-x1.localdomain>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Qemu-devel] Coding style for errors
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Stefan Hajnoczi <stefanha@gmail.com>, Markus Armbruster <armbru@redhat.com>, qemu-devel@nongnu.org, Peter Maydell <peter.maydell@linaro.org>, Eric Blake <eblake@redhat.com>

On 10/23/15 18:01, Stefan Hajnoczi wrote:
> On Thu, Oct 22, 2015 at 03:30:34PM +0200, Llu=EDs Vilanova wrote:
>> Markus Armbruster writes:
>>
>>> Llu=EDs Vilanova <vilanova@ac.upc.edu> writes:
>> [...]
>>>> So, is there any agreement on what should be used? If so, could that=
 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 t=
o other
>> functions you think are important. I'll send a patch once we agree on =
the text.
>>
>> Cheers,
>>   Lluis
>>
>>
>> 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.

I thought that's what we have now; for example, a buggy video driver can
lock up or crash the entire box. Faithful emulation FTW! ;)

> This may mean that the device becomes non-operational (ignores
> or fails new requests) until the next hard or soft reset.
>=20