Re: [Qemu-devel] sub-page-sized mmio regions and address passed to read/write fns

[Avi Kivity <avi@redhat.com>]

On 12/04/2011 11:15 PM, Peter Maydell wrote:
> On 4 December 2011 12:17, Avi Kivity <avi@redhat.com> 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
> referring to:
>
> # 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.

Not an issue in the subpage code.  As long as you extract the mmio index
before adding region_offset, you're fine (as the mmio index resides in
the low order 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
> >> else.)
>
> > 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.

In that case we have to use subpages for full pages.  But better to just
assert() that this never happens for now.

-- 
error compiling committee.c: too many arguments to function