On 4 August 2017 at 19:09, Philippe Mathieu-Daudé <f4...@amsat.org> wrote:
> On 08/04/2017 02:20 PM, Peter Maydell wrote:
>> We need this for ARM boards, where we're about to implement support for
>> generating external aborts on memory transaction failures. Too many
>> of our legacy board models rely on the RAZ/WI behaviour and we
>> would break currently working guests when their "probe for device"
>> code provoked an external abort rather than a RAZ.

> I think some firmware will give some surprises, those probing device is not
> here and expect RAZ/WI. I remember some fw probing PCI space, or enumerating
> CS this way for ex.

PCI space is funny anyway because IIRC the PCI spec mandates
RAZ/WI (which is handled by QEMU's PCI implementation I think,
it doesn't fall out to the memory system's unmapped-address

That said: yes, possibly some guest code really wants the fault
(indeed the motivation for this patchset was having some test
guest code which wanted to see the faults), but that guest code
won't work on QEMU today, so if it doesn't boot on QEMU with
this patchsets that's not a regression. We can then (as the
issue arises) look at fixing whatever particular board model
it is to properly model or stub out all its devices so we
can boot that guest code without breaking existing working
guest code.

> RAZ/WI is a bus-feature, this is also bus-dependent to reply with abort or
> behave RAZ/WI. Maybe the effort should be done on how model/use buses in
> QEMU? Bus device would be an alias of unimplemented_device, which current
> purpose is more debugging than avoiding unassigned physical access aborts.

You can model this kind of bus-dependent behaviour by having
the bus register a background region which implements the
default behaviour that is desired. (That way accesses to
that part of the address space don't ever respond with
a transaction error, which is what's happening on hardware
where the bus doesn't report errors.)

-- PMM

Reply via email to