On 5 January 2017 at 20:18, Jean-Christophe DUBOIS <j...@tribudubois.net> wrote: > Le 05/01/2017 à 21:04, mar.krzeminski a écrit : >> Peter Maydell wrote: >>> If these are "can't happen unless some other part of QEMU >>> is buggy" cases, then we can just assert():
>>> (If they're "could happen if the guest does something wrong" >>> cases, we shouldn't just abort(), but if I'm reading the previous >>> mail thread correctly, that's not the situation here.) > >> Indeed this case is about error in Qemu itself, but the same situation could >> be generated from the guest (guest deasert CS only once). >> IMHO we should reset m26p80 state in such case: >> s->len = 0; >> s->pos = 0; >> s->state = STATE_IDLE; >> This will be a bit closer to real HW behaviour too. > So what would be the preferred behavior? > > Asserting (and ending Qemu) > Resetting (and hiding the misbehavior). If the guest can trigger this behaviour, then we should not assert or abort or otherwise cause QEMU to exit. The preferred behaviour is: * act like the real hardware does in this situation (whatever that is) * if this is something that only broken guest code would do, log it with qemu_log_mask(LOG_GUEST_ERROR, ...) thanks -- PMM
