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

["Andreas Färber" <afaerber@suse.de>]

Am 05.08.2013 11:59, schrieb Peter Maydell:
> 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.

Yes, that's what I thought someone brought up in one of those lengthy
memory discussions: Accesses between the first two [io]s would now seem
to go to [io region] rather than into [system memory region] subregions
at the same level as [io region].

> Do we have any boards that do that?

Sorry, I don't remember who brought it up, hopefully Paolo remembers?
Possibly sPAPR?

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg