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

[Peter Maydell <peter.maydell@linaro.org>]

On 5 August 2013 10:34, Andreas Färber <afaerber@suse.de> wrote:
> Am 03.08.2013 10:31, schrieb Jan Kiszka:
>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>
>> Accesses to unassigned io ports shall return -1 on read and be ignored
>> on write. Ensure these properties via dedicated ops, decoupling us from
>> the memory core's handling of unassigned accesses.
>>
>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
>> ---
>>  exec.c                |    3 ++-
>>  include/exec/ioport.h |    2 ++
>>  ioport.c              |   16 ++++++++++++++++
>>  3 files changed, 20 insertions(+), 1 deletions(-)
>>
>> diff --git a/exec.c b/exec.c
>> index 3ca9381..9ed598f 100644
>> --- a/exec.c
>> +++ b/exec.c
>> @@ -1820,7 +1820,8 @@ static void memory_map_init(void)
>>      address_space_init(&address_space_memory, system_memory, "memory");
>>
>>      system_io = g_malloc(sizeof(*system_io));
>> -    memory_region_init(system_io, NULL, "io", 65536);
>> +    memory_region_init_io(system_io, NULL, &unassigned_io_ops, NULL, "io",
>> +                          65536);
>
> It was reported that there may be some machines/PHBs that have
> overlapping PIO/MMIO. Unless we use priorities, this ..._io MemoryRegion
> will shadow or conflict with any ..._io MemoryRegion added to the memory
> address space, wouldn't it?

Priorities only apply between different subregions within a
container. This is adding IO operations to the container itself,
so there's no priority issue here: the container's operations
always come last, behind any subregions it has.

(Do we have any existing examples of container regions with their
own default IO operations? The memory.c code clearly expects them
to be OK, though - eg render_memory_region() specifically does
"render subregions; then render the region itself into any gaps".)

Or do you mean that if we had:

 [ system memory region, with its own default read/write ops ]
     [ io region mapped into it ]
         [ io ]   [ io ][io]

that now if you access the bit of system memory corresponding
to the I/O region at some address with no specific IO port,
you'll get the IO region's defaults, rather than the system
memory region's defaults? I think that's true and possibly
a change in behaviour. Do we have any boards that do that?

-- PMM