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

["Philippe Mathieu-Daudé" <philmd@linaro.org>]

On 23/6/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.

Since commit 21786c7e59 ("softmmu/memory: Log invalid memory accesses")
you can log the failed transaction with '-d guest_errors'. See for
example commit a13bfa5a05 ("hw/mips/jazz: Map the UART devices
unconditionally"):

   $ qemu-system-mips64el -M magnum -d guest_errors,unimp -bios NTPROM.RAW
   Invalid access at addr 0x80007004, size 1, region '(null)', reason: 
rejected
   Invalid access at addr 0x80007001, size 1, region '(null)', reason: 
rejected
   Invalid access at addr 0x80007002, size 1, region '(null)', reason: 
rejected
   Invalid access at addr 0x80007003, size 1, region '(null)', reason: 
rejected
   Invalid access at addr 0x80007004, size 1, region '(null)', reason: 
rejected

Boards booting successfully with ignore_memory_transaction_failures
set can often remove this flag by mapping missing accessed ranges as
TYPE_UNIMPLEMENTED_DEVICE. (You can then log the same accesses using
'-d unimp').