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). > >> In fact we will probably have to add more details to the memory >> hierarchy. Currently (for example) we model the memory hub passing >> transactions destined for the various pci windows to the pci bus, but we >> don't model the memory hub receiving a pci-initiated transaction and >> passing it to the system bus. We simply pretend it originated on the >> system bus in the first place. Perhaps we need parallel hierarchies: >> >> system_memory >> alias -> pci >> alias -> ram >> pci >> bar1 >> bar2 >> pcibm >> alias -> pci (prio 1) >> alias -> system_memory (prio 0) >> >> cpu_physical_memory_rw() would be implemented as >> memory_region_rw(system_memory, ...) while pci_dma_rw() would be >> implemented as memory_region_rw(pcibm, ...). This would allow different >> address transformations for the two accesses. > > Ideally system_memory shouldn't exist at all. Anything > which can issue transactions should do it by exposing > a suitable interface which the system model can then > just wire up suitably. Obviously mostly that's going > to be "all these devices go here in the memory map and > that view of the world is what all the CPUs see", but > we shouldn't have a globally accessible and implicitly > used address space IMHO. > > (For instance, the right way to model per-CPU devices > is to have each individual CPU core expose its transaction > master, and then you wire the per-CPU devices up only > to their corresponding CPU.) Correct. system_memory would be renamed cpu_memory, and would be cpu local (since some systems allow each cpu to have a different memory map). phys_map would be a cache for the memory map that can be seen through that region; we might make it a field of MemoryRegion. -- error compiling committee.c: too many arguments to function
