On 5 August 2017 at 11:13, Peter Maydell <peter.mayd...@linaro.org> wrote: > On 4 August 2017 at 20:23, Richard Henderson > <richard.hender...@linaro.org> wrote: >> On 08/04/2017 11:09 AM, Philippe Mathieu-Daudé wrote: >>> Since create_unimplemented_device() register overlapped with low priority, >>> why >>> not register it as default device directly, over the whole address space? >> >> That's a good suggestion. It makes more sense to me than adding a flag on >> the >> MachineClass. > > Yeah, I did think about implementing it that way, but... > > That wouldn't handle the case of a device model directly > returning a MEMTX_ERROR, or a transaction dispatched to > a memory region whose MemoryRegionOps valid settings > prohibit it (eg byte accesses to a word-access-only device), > or accesses to a MemoryRegion that was created by passing > a NULL MemoryRegionOps pointer to memory_region_init_io > (I dunno why you'd do that but some code does). > > In short, there are lots of ways the memory subsystem might > end up returning a transaction error -- this mechanism > ensures that none of them start generating exceptions > when they previously did not, and is (I hope) easy to > review in the sense of being sure that it does what it > intends to do without the need to audit a lot of corner > cases.
So, this question (should we have a board flag to disable reporting of tx failures to the CPU hook, or use unimplemented_device as a sort of background region) seems to be the main unanswered question for this series. I think (as outlined above) that the board flag is simpler and safer; are people happy for me to put this series in target-arm.next with that approach, or should I rethink this bit? thanks -- PMM
