Re: [Qemu-devel] Coding style for errors

[Laszlo Ersek]

On 10/23/15 18:01, Stefan Hajnoczi wrote:
> On Thu, Oct 22, 2015 at 03:30:34PM +0200, Lluís Vilanova wrote:
>> Markus Armbruster writes:
>>
>>> Lluís Vilanova <address@hidden> 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.

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.
>