Re: [Qemu-devel] [PATCH] memory: simple memory tree printer

[Jan Kiszka]

On 2011-09-14 17:10, Richard Henderson wrote:
> On 09/12/2011 02:19 AM, Jan Kiszka wrote:
>> On 2011-09-12 11:11, Avi Kivity wrote:
>>> On 09/12/2011 12:01 PM, Jan Kiszka wrote:
>>>> On 2011-09-12 08:43, Richard Henderson wrote:
>>>>>  On 09/11/2011 09:31 PM, Blue Swirl wrote:
>>>>>>  Field 'offset' is always zero, maybe that is not interesting. Will it
>>>>>>  become one day?
>>>>>
>>>>>  It's not always zero, but only used by certain devices.
>>>>
>>>> I do not see any users, neither upstream nor in Avi's tree.
>>>
>>> There aren't.
>>>
>>>> To my (semi-)understanding, offset should correlate to region_offset of
>>>> cpu_register_physical_memory_offset: legacy device models require this
>>>> to be 0 as they expect an absolute memory address passed to their
>>>> handler, in contrast to a normal one that is relative to the regions
>>>> base. But I do not see how the memory region offset actually helps here.
>>>>
>>>
>>> mr->offset is added to the address in memory_region_{read,write}_thunk_n().
>>
>> Ah, ok.
>>
>> So the default address passed to the handler is now already relative? I
>> think we should keep it like this for all converted devices, ie. take
>> the chance, fix the remaining models, and drop the offset.
> 
> It's non-zero for the isa portio conversion that I did, which
> I thought was in Avi's tree.

Hmm, I wasn't looking at PIO yet as it was out of scope of the original
MMIO offset. But good to known.

> 
> This is required by at least the VGA and GUS ISA devices which
> do expect absolute i/o addresses, and check them.  The offset is
> used to convert the relative i/o address back into an absolute
> address.

If those are the only users, let's adjust them.

> 
> It would also be used when we split an ISA portio region, as 
> with the FDC device.  There, we have 7 ports in 2 chunks.  The
> offset would still be needed to convert the relative offset of
> the second chuck to be relative to the "real" un-split region.

That sounds a lot like it only affects the flattened representation, and
there an offset does make sense. But we are discussing the original
memory regions here that should not require it (provided the above
cleanup is applicable).

> 
> Feel free to convert all of these devices to a more "native" use
> of the memory api, but I warn you it won't be trivial.

Do you mean VGA and GUS or FDC?

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux