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

[Anthony Liguori <anthony@codemonkey.ws>]

On 06/11/2012 12:31 PM, Avi Kivity wrote:
> On 06/11/2012 06:01 PM, Anthony Liguori wrote:
>> On 06/11/2012 08:39 AM, Peter Maydell wrote:
>>> On 11 June 2012 14:15, Anthony Liguori<aliguori@us.ibm.com>   wrote:
>>>>    From what you said earlier, it's basically:
>>>>
>>>> 'write data to this address'
>>>> 'read data from this address'
>>>>
>>>> An interface that implements this is DMAContext.  Forget about the
>>>> fact that
>>>> 'DMA' is in the name.  It's really the symmetric version of a
>>>> MemoryRegion.
>>>
>>> ...so can we fix the name?
>>
>> Perhaps we should just make MemoryRegion work in both directions?
>>
>> Ben/Avi, what do you guys think?
>>
>
> 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.
>
> 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.

BTW, the main problem with the memory API right now is that there isn't a 
'MemoryRegion *mr' as the first argument to the dispatch functions.  This could 
be fixed by introducing yet another set of function pointers and keeping the 
existing callers unchanged though.

Regards,

Anthony Liguori

>
>