On 12 June 2012 14:18, Avi Kivity <a...@redhat.com> wrote: > On 06/12/2012 03:58 PM, Peter Maydell wrote: >> On 11 June 2012 18:31, Avi Kivity <a...@redhat.com> wrote: >>> On 06/11/2012 06:01 PM, Anthony Liguori wrote: >>>> Perhaps we should just make MemoryRegion work in both directions? >> >>> The other direction is currently cpu_physical_memory_rw(). We do need >>> to support issuing transactions from arbitrary points in the memory >>> hierarchy, but I don't think a device's MemoryRegion is the right >>> interface. Being able to respond to memory transactions, and being able >>> to issue them are two different things. >> >> ...they're just opposite sides of the same interface, though, >> really. For instance you could say that any memory transaction >> master (cpu, dma controller, whatever) should take a single >> MemoryRegion* and must issue all its memory accesses to that MR*. >> (obviously that would usually be a container region.) > > It would be a container region, and it would be unrelated to any other > regions held by the device (the device might not have any memory > regions; instead it would only be able to do dma).
It shouldn't actually be owned by the transaction master, but by whatever the parent object is that created the transaction master. So for instance for an ARM board you'd have something like: * top level machine QOM object creates a 'system-memory' container region, and puts all the devices in it in their correct locations * top level object also creates the cortex-a9 device, and passes it a pointer to the system-memory container * the cortex-a9 device instantiates the CPU cores and the per-cpu devices, and creates a container region for each cpu containing (devices for that cpu, plus the system-memory region it got passed). It passes a pointer to the right region to each cpu core * the cpu cores just use the region they're given * if there's a dma controller in the system, the top level machine object creates the controller and hands it a pointer to the system-memory container region too. (So the dma controller correctly doesn't see the per-cpu devices.) (when I say 'passes a pointer' I mean something involving QOM links I expect. I'm not sure if anybody's thought about how we expose memory regions in a QOM manner.) Notice that in this approach it's perfectly valid to have a board model which creates a single device and a single CPU and passes the device's MemoryRegion directly to the CPU. This corresponds to a hardware design where the CPU's address lines just connect straight to the device's, ie there's no bus fabric or address decoding. -- PMM