Re: [Qemu-devel] [RFC] QOMification of AXI stream

[Avi Kivity <avi@redhat.com>]

On 06/12/2012 03:58 PM, Peter Maydell wrote:
> On 11 June 2012 18:31, Avi Kivity <avi@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