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

[Edgar E. Iglesias]

On Thu, Jun 14, 2012 at 11:34:10AM +1000, Benjamin Herrenschmidt wrote:
> 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.

Thanks for the clarificatino Ben.

I don't know much about PCI but in the embedded world I've never seen
anything that resemblems what you describe. Devices at the bottom of
the hierharcy (or at any location) that make acceses to the memory system
do it through a different port located at a differnt logical position in
the hierarchy. In fact, a DMA ctrl can through it's master port access it's
slave port without it even noticing that it is the same device accessing
itself and the access will travel top-down through the bus hierarchy.

I've never seen address decoding beeing done in reverse.. bottom-up.

Cheers