qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] sub-page-sized mmio regions and address passed to read/writ


From: Peter Maydell
Subject: [Qemu-devel] sub-page-sized mmio regions and address passed to read/write fns
Date: Fri, 2 Dec 2011 14:49:55 +0000

Hi; I was working on a refactoring of the ARM 11MPCore/A9MP private
peripherals and encountered something odd. Rather than having a single
large mmio region, I tried splitting into several regions, like this:

    memory_region_init(&s->container, "a9mp-priv-container", 0x2000);
    memory_region_init_io(&s->scu_iomem, &a9_scu_ops, s, "a9mp-scu", 0x100);
    memory_region_init_io(&s->gic_cpu_iomem, &a9_gic_cpu_ops, s,
                          "a9mp-gic-cpu", 0x100);
    memory_region_init_io(&s->ptimer_iomem, &a9_ptimer_ops, s,
                          "a9mp-ptimer", 0x100);
    memory_region_add_subregion(&s->container, 0, &s->scu_iomem);
    memory_region_add_subregion(&s->container, 0x100, &s->gic_cpu_iomem);
    memory_region_add_subregion(&s->container, 0x600, &s->ptimer_iomem);
    memory_region_add_subregion(&s->container, 0x1000, &s->gic.iomem);
    sysbus_init_mmio_region(dev, &s->container);

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

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.)

-- PMM



reply via email to

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