Re: [Qemu-devel] [PATCH] [m25p80] Abort in case we overrun the internal data buffer

[Jean-Christophe DUBOIS]

Le 05/01/2017 à 21:51, Peter Maydell a écrit :
> > 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, ...)

I guess a real SPI controllers should not trigger this behavior like I 
did in the i.MX SPI controller emulation. It was a bug in my code and 
the crash (SIGSEGV) forced me to try to find a solution. At first I 
tried to fix the SPI device instead of the SPI controller because a 
SIGSEGV did not seem like an expected reaction and I was missing hints 
that my code was misbehaving.

But it is also possible for a guest to emulates the SPI controller 
through bit banging (for example). And in this case the guest could end 
up misbehaving in its software implementation.

So I think this behavior could be triggered either by buggy SPI 
controller emulator or by buggy guest software. And it seems hard to 
determine where the fault comes from from within Qemu. Obviously if the 
fault is in a Qemu emulator we would not want to tag the error as a 
LOG_GUEST_ERROR. On the other hand, it would be nice to warn the user if 
the guest if it is indeed misbehaving so that he can fix his code.

> thanks
> -- PMM