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

[Benjamin Herrenschmidt]

On Thu, 2012-06-14 at 02:00 +0200, Edgar E. Iglesias wrote:
> 
> TBH, I don't understand any of the "upstream" access discussion nor
> the specifics of DMA accesses for the memory/system bus accesses.
> 
> When a device, like a DMA unit accesses the memory/system bus it,
> AFAIK, does it from a different port (its master port). That port is
> NOT the same as it's slave port.

It may or may not be but yes, in most case the slave and master
interfaces can be seen as different interfaces to the bus though in many
case they aren't completely independent (there are ordering guarantees
in some cases for example).

>  There is no reverese decoding of the
> addresses, the access is made top-down. If you are talking about NoCs
> we need a compleet different infrastructure but I don't think that
> is the case.

I don't parse the above. But the simple example is to look at PCI.

When a PCI device initiates an access, what happens is that it gets
arbitration on its bus segment, and from there it's purely an ordinary
PCI access for the address specified by that device.

Depending on other devices, bridges, etc... that access may travel
upstream or to a sibling (which can be a bridge and thus go back down)
etc...

Along that hierarchy, transforms might occur, which can be different
depending on the direction. For example the PCI host controller might
contain an iommu (typically that's the case with IBM pseries one) while
on the downstream direction it has a handful of relatively fixed
windows.

But there are other cases, the processor bus can be bridged to some
other IO bus (PLB4, PLB6, AXI) which can itself be bridge to some other
simpler bus (OPB, AHB, ...) and in some case there can be transforms
done along the way. Some may and some may not support DMA, or with
address limitation, etc... there's a bit of everything out there.

> I agree with Avi, most of it is already in place.

Well, not quite in that we need to traverse the memory hierarchy
starting from the device itself and have rules at the various "bridge"
levels on how to forward/transform things in the upstream direction
(though as the discussion showed earlier, we could use some better
support for downstream transforms as well).

I think we can probably stick to a mechanism that has two basic
function:

 - Either the transform (or lack of) can be represented by an offset to
be applied to the address (which would match most of the bit
mask/replace cases)

 - Or the transform is a function pointer

The former would represent most cases and would provide the ability to
"flatten the tree" by storing fully transformed ranges from the CPU
point of view (it might be tricky to have a variant of these for every
device) in order to speed up accesses. The latter would typically be
used by iommu's.

Now if you guys think you can cook up the necessary infrastructure
changes in the next couple of weeks, I'm happy to completely drop
DMAContext.

In any case, better accessors are a good thing so I'll start with the
first few patches of David's series and polish them to add proper pci_
and vio_ accessors for use by devices while we iron out what we want to
do with the infrastructure.

Cheers,
Ben.