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