On 22 November 2011 00:27, Peter Chubb <peter.ch...@nicta.com.au> wrote: >>>>>> "Peter" == Peter Maydell <peter.mayd...@linaro.org> writes: > > Peter> On 21 November 2011 23:54, Peter Chubb > Peter> <pet...@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
