Re: [Qemu-devel] [PATCH 1/2] memory: Provide separate handling of unassigned io ports accesses

[Peter Maydell]

On 5 August 2013 11:44, Jan Kiszka <address@hidden> wrote:
> On 2013-08-05 12:36, Peter Maydell wrote:
>> On 5 August 2013 11:30, Jan Kiszka <address@hidden> 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