[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Avi Kivity
Subject: Re: [Qemu-devel] [RFC] QOMification of AXI stream
Date: Mon, 11 Jun 2012 20:31:08 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1

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<address@hidden>  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:

      alias -> pci
      alias -> ram
      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.

I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]