[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] sub-page-sized mmio regions and address passed to read/
Re: [Qemu-devel] sub-page-sized mmio regions and address passed to read/write fns
Sun, 4 Dec 2011 21:15:14 +0000
On 4 December 2011 12:17, Avi Kivity <address@hidden> wrote:
> On 12/02/2011 04:49 PM, Peter Maydell wrote:
>> However what I found is that the addresses passed to the read/write
>> functions aren't what I would expect. For instance if the board
>> maps the container at address 0x1e000000, then a read from 0x1e000100
>> goes to the functions given by a9_gic_cpu_ops, as it should. However,
>> the offset parameter that the read function is passed is not 0x0
>> (offset from the start of the a9mp-gic-cpu region) but 0x100 (offset
>> from the start of the page, I think).
>> Is this expected behaviour? I certainly wasn't expecting it...
> A while ago this was the behaviour across the board. Then 8da3ff1809747
> changed addresses to be relative, but apparently missed the subpage case.
Having looked a bit more closely at the code I think this is what
the comment at the top of cpu_register_physical_memory_log() is
# Both start_addr and region_offset are rounded down to a page boundary
# before calculating this offset. This should not be a problem unless
# the low bits of start_addr and region_offset differ.
In the case of a subregion at a non-page-aligned-address the
start_addr is not page aligned, but the region_offset is zero,
in the usual case, so we have differing low bits.
>> I looked through the code that's getting called for reads, and
>> it looks to me like exec.c:subpage_readlen() is causing this.
>> We look up the subpage_t based on the address within the page,
>> but we don't then adjust the address we pass to io_mem_read
>> (except by region_offset, which I take from the comment at the
>> top of cpu_register_physical_memory_log() to be for something
> I think you can use subpage_t's region_offset array for this (adding
> into it, of course, so the original value remains).
Yes. I think the correction has to be calculated and applied in
cpu_register_physical_memory_log() -- for a region which starts
at a non-page-aligned address and extends over more than a page
the correcting offset needs to be applied for the whole region,
not just the first partial page.