On 5 August 2013 11:44, Jan Kiszka <jan.kis...@web.de> wrote: > On 2013-08-05 12:36, Peter Maydell wrote: >> On 5 August 2013 11:30, Jan Kiszka <jan.kis...@web.de> wrote: >>> On 2013-08-05 11:59, Peter Maydell wrote: >>>> Or do you mean that if we had: >>>> >>>> [ system memory region, with its own default read/write ops ] >>> >>> I cannot imagine how this could work. The system memory region has no >>> clue about what the regions below it can handle and what not. So it has >>> to pass through the io window. >> >> The system memory region's just a container, you can add a >> background region to it at lowest-possible-priority, which >> then takes accesses which are either (a) not in any subregion >> or (b) in a subregion but that container doesn't specify >> its own io ops and nothing in that container handles the >> access. (Or you could create the system memory region with >> its own IO ops, which would have the same effect.) > > First, we do not render MMIO and IO within the same address space so > far.
Is this a statement made because you've checked all the boards and know that nobody's mapping the system-io memory region into the system-memory region? (It is technically trivial, you just need to call memory_region_add_subregion() directly or indirectly...) > But even if we would, the IO container now catches all accesses, so > the system memory region will never have its default handler run for > that window. Yes, that is the point -- before the IO container caught all accesses, the default handler that would run would be the system memory region, but now that the IO container has default read/write ops they will take precedence. So this would be a behaviour change if there are any boards set up like this. (I'm not sure there are any, though.) -- PMM