Re: [Qemu-devel] Coding style for errors

[Stefan Hajnoczi <stefanha@gmail.com>]

On Thu, Oct 22, 2015 at 03:30:34PM +0200, Lluís Vilanova wrote:
> Markus Armbruster writes:
> 
> > Lluís 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 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 (ignores
or fails new requests) until the next hard or soft reset.