Re: [Qemu-devel] Coding style for errors

[Thomas Huth]

On 23/10/15 19:02, Dr. David Alan Gilbert wrote:
> * Stefan Hajnoczi (address@hidden) 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.  This may mean that the device becomes non-operational (ignores
>> 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).

... and call qemu_system_guest_panicked() so that the management layers
can flag the guest accordingly?

 Thomas