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 handling). 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.) thanks -- PMM
