Stefan Hajnoczi writes: > On Thu, Oct 22, 2015 at 03:30:34PM +0200, Lluís Vilanova wrote: >> Markus Armbruster writes: >> >> > Lluís Vilanova <vilan...@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. I'm not sure how this should be translated into the form of error-reporting guidelines. Thanks, Lluis -- "And it's much the same thing with knowledge, for whenever you learn something new, the whole world becomes that much richer." -- The Princess of Pure Reason, as told by Norton Juster in The Phantom Tollbooth
