qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Philippe Mathieu-Daudé
Subject: Re: [PATCH 0/4] target/ppc: Catch invalid real address accesses
Date: Sat, 24 Jun 2023 01:35:28 +0200
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.12.0

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').




reply via email to

[Prev in Thread] Current Thread [Next in Thread]