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