Re: [Qemu-devel] [PATCH] imx.31 and KZM board support

[Peter Maydell <peter.maydell@linaro.org>]

On 22 November 2011 00:27, Peter Chubb <peter.chubb@nicta.com.au> wrote:
>>>>>> "Peter" == Peter Maydell <peter.maydell@linaro.org> writes:
>
> Peter> On 21 November 2011 23:54, Peter Chubb
> Peter> <peterc@gelato.unsw.edu.au> wrote:
>>> Do you have a suggestion for an alternative to hw_error for guest
>>> bad behaviour?  It seems to be used historically.  For emulating
>>> ARM, causing qemu to stop isn't such a bad idea ... the guest does
>>> something wrong and the qemu instance dies with a message.  It's
>>> not as it that'll affect any other guests, each of which will have
>>> their own qemu instance.
>
> Peter> The question's come up before and we don't currently have a
> Peter> good API for it. Personally I prefer "silently ignore" for the
> Peter> moment; hardware doesn't chatter at you about guest OS
> Peter> misbehaviour...
>
> Speaking as an OS developer I'd much prefer to have the simulator yell
> at me when my code tries to write to bad registers.  That's one of the
> reasons I try to use the emulator rather than the real hardware --- it
> allows one to find bugs otherwise invisible.

Yes, this is the trouble -- different audiences want different levels
of chattiness from qemu. An app developer/user basically doesn't care
if the OS is doing something slightly dubious because they have no
way to fix it anyhow. So you need a user-controllable verbosity level.
(And some OSes do dubious things at great rate, eg Linux on OMAP
deliberately touches a nonexistent register in its interrupt handler
path and if we warned every time we'd generate a huge volume of warnings.
So some kind of rate limit/"warned ten times about this already, don't
warn any more" would eb good too.)

But I think "kill qemu" is pretty definitely not the right thing
(unless the hardware bursts into flames if you access the bad
register, in which case maybe...)

-- PMM