On Mon Jun 26, 2023 at 11:35 PM AEST, Cédric Le Goater wrote: > On 6/23/23 14:37, Cédric Le Goater wrote: > > On 6/23/23 11:10, Peter Maydell wrote: > >> On Fri, 23 Jun 2023 at 09:21, Nicholas Piggin <npig...@gmail.com> wrote: > >>> > >>> ppc has always silently ignored access to real (physical) addresses > >>> with nothing behind it, which can make debugging difficult at times. > >>> > >>> It looks like the way to handle this is implement the transaction > >>> failed call, which most target architectures do. Notably not x86 > >>> though, I wonder why? > >> > >> Much of this is historical legacy. QEMU originally had no > >> concept of "the system outside the CPU returns some kind > >> of bus error and the CPU raises an exception for it". > >> This is turn is (I think) because the x86 PC doesn't do > >> that: you always get back some kind of response, I think > >> -1 on reads and writes ignored. We added the do_transaction_failed > >> hook largely because we wanted it to give more accurate > >> emulation of this kind of thing on Arm, but as usual with new > >> facilities we left the other architectures to do it themselves > >> if they wanted -- by default the behaviour remained the same. > >> Some architectures have picked it up; some haven't. > >> > >> The main reason it's a bit of a pain to turn the correct > >> handling on is because often boards don't actually implement > >> all the devices they're supposed to. For a pile of legacy Arm > >> boards, especially where we didn't have good test images, > >> we use the machine flag ignore_memory_transaction_failures to > >> retain the legacy behaviour. (This isn't great because it's > >> pretty much going to mean we have that flag set on those > >> boards forever because nobody is going to care enough to > >> investigate and test.) > >> > >>> Other question is, sometimes I guess it's nice to avoid crashing in > >>> order to try to quickly get past some unimplemented MMIO. Maybe a > >>> command line option or something could turn it off? It should > >>> probably be a QEMU-wide option if so, so that shouldn't hold this > >>> series up, I can propose a option for that if anybody is worried > >>> about it. > >> > >> I would not recommend going any further than maybe setting the > >> ignore_memory_transaction_failures flag for boards you don't > >> care about. (But in an ideal world, don't set it and deal with > >> any bug reports by implementing stub versions of missing devices. > >> Depends how confident you are in your test coverage.) > > > > It seems it broke the "mac99" and powernv10 machines, using the > > qemu-ppc-boot images which are mostly buildroot. See below for logs. > > > > Adding Mark for further testing on Mac OS. > > > Mac OS 9.2 fails to boot with a popup saying : > > Sorry, a system error occured. > "Sound Manager" > address error > To temporarily turn off extensions, restart and > hold down the shift key > > > Darwin and Mac OSX look OK.
Might have to to restrict it to POWER machines for now then. Seems like it will break working systems. We could just log a guest error for the others. Thanks, Nick
