On 30/04/12 14:27, Peter Maydell wrote:
Hi Peter,
IMO the best fix is to unsysbus the device and qomify it instead. This
way we're 100% flexible in how we can attach it.
You don't need to wait for QOM to grow enough features to
replace sysbus. If you don't like what sysbus_mmio_map() does, you
Oh - so does this mean that QOM is not feature-complete?
can always use sysbus_mmio_get_region() to get the MemoryRegion* and
then deal with it however you need to. This is the standard way
to deal with "I have a sysbus device which I want to map into my
custom container object".
I already have code to do this for the sun4m-only hardware modelled on
sysbus_mmio_map() like this:
static void sbus_mmio_map(void *sbus, SysBusDevice *s, int n,
target_phys_addr_t addr)
{
MemoryRegion *sbus_mem, *mem;
target_phys_addr_t sbus_base;
SBusState *sbus_state = FROM_SYSBUS(SBusState, (SysBusDevice *)sbus);
sbus_mem = sysbus_mmio_get_region((SysBusDevice *)sbus, 0);
mem = sysbus_mmio_get_region(s, n);
/* SBus addresses are physical addresses, so subtract start of
region */
sbus_base = sbus_state->base;
memory_region_add_subregion(sbus_mem, addr - sbus_base, mem);
}
The key problem is that this doesn't worked with shared peripherals,
such as the ESP device which is also used on various PPC Mac models as
well as SPARC. That's because its init function looks like this:
void esp_init(target_phys_addr_t espaddr, int it_shift,
ESPDMAMemoryReadWriteFunc dma_memory_read,
ESPDMAMemoryReadWriteFunc dma_memory_write,
void *dma_opaque, qemu_irq irq, qemu_irq *reset,
qemu_irq *dma_enable)
{
...
...
sysbus_mmio_map(s, 0, espaddr);
...
}
Therefore I can't change it to my (modified) sbus_mmio_map() function
because it would break other non-SPARC platforms, and AIUI there is
nothing in the memory API that allows me to move a subregion to a
different MemoryRegion parent, even if I can get a reference to it with
sysbus_mmio_get_region() after the sysbus_mmio_map() call - or have I
misunderstood something?
ATB,
Mark.
