Re: [PATCH 0/4] target/ppc: Catch invalid real address accesses

["Nicholas Piggin" <npiggin@gmail.com>]

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 <npiggin@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