[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Richard Henderson
Subject: Re: [Qemu-devel] [PATCH] memory: simple memory tree printer
Date: Wed, 14 Sep 2011 08:10:58 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2

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

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]