[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Jean-Christophe DUBOIS
Subject: Re: [Qemu-devel] [PATCH] [m25p80] Abort in case we overrun the internal data buffer
Date: Thu, 5 Jan 2017 22:39:39 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1

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.

-- PMM

reply via email to

[Prev in Thread] Current Thread [Next in Thread]