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.
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.
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.
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.
r~
