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

[Anthony Liguori]

On 06/08/2012 08:24 PM, Peter Crosthwaite wrote:
> On Sat, Jun 9, 2012 at 12:15 AM, Anthony Liguori<address@hidden>  wrote:
> > On 06/08/2012 12:23 PM, Peter Crosthwaite wrote:
> > > Hi all,
> > >
> > > Im looking to QOMifying and refactoring the AXI stream interfaces
> > > between the AXI ethernet and AXI DMA modules. I could use some
> > > guidance on how to do this as I can think of about 6 different
> > > solutions. Sources are hw/xilinx_axienet.c and hw/xilinx_axidma.c.
> > >
> > > First ill start off by describing the real hardware:
> > >
> > > Each of the two core has three interfaces (+interrupt pins):
> > >
> > > 1: Sysbus attachment for device control
> > > 2: AXI stream TX link
> > > 3: AXI stream RX link
> > >
> > > Ethernet packet data is transferred from the ethernet device to/from
> > > memory via the AXI stream links and the DMA core. Basically the DMA
> > > core can be summed up as simply taking data to/from memory and putting
> > > to/from the axi stream links. Axi stream is a trival point to point
> > > protocol that allows for pushing 32-bit data words at a time.
> > >
> > >   From an architecture point of view, the TX and RX links are completely
> > > independent of each other. It doesnt make a lot of sense to have tx or
> > > rx without the other for the ethernet with DMA case, but other
> > > applications of the DMA could use only one of tx and rx. For this
> > > reason I think its best we decouple the tx/rx pair. Currently it is
> > > coupled in qemu (hw/xilinx_axdma.h):
> >
> >
> > So is this something that should be modeled as a DMAContext ala dwg/benh's
> > IOMMU patch series?
> >
> > Wouldn't the DMA controller expose two or more DMAContextes and then the
> > Ethernet device expects a DMAContext for tx and rx.
>
> Hi Anthony,
>
> This doesn't sound right to me at all WRT to modelling the real
> hardware. The ethernet controller on its own has no notion that it is
> attached to a DMA controller. I can attached the device to any
> AXI-stream tx/rx pair. The ethernet device should only has awareness
> of the axi stream protocol and have no exposure to any DMA related
> functionality.

What is the AXI stream protocol?

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.

> Heres the (futuristic) example im worried about:
>
> I have my ethernet controller attached to the DMA as usual over the
> axi-stream pairs. I then come along and decide I want to model some
> hardware packet filter device on the ethernet traffic inbetween the
> memory and ethernet. My packet filter is implemented as a axi-stream
> master and slave (basically a filtering fifo). I need to on the
> machine model level, insert it on the rx path. Heres the architecture:
>
> Ethernet ->  axistream ->  Random packet filter IP ->  axistream ->  DMA
>
> Ethernet<- axistream<- DMA
>
> In this case the ethernet is insulated from DMA. I think i can
> summarize in saying that assuming that an axi-stream link is for DMA
> is incorrect.

So first thing you need to do is figure out what the stream interface consists 
of.  You can model this as an Interface or use an existing Interface (like 
DMAContext).  You can then expose a pair of these interfaces from the controller 
using a child object (as Paul likes to say, a proxy object).  This is how 
MemoryRegions and DMAContexts work.

Regards,

Anthony Liguori

> Regards,
> Peter
>
> > Of course, DMAContext could be made trivially into an Object and tx/rx could
> > be turned into link<>  properties.
> >
> > Regards,
> >
> > Anthony Liguori
> >
> >
> > > struct XilinxDMAConnection {
> > >      void *dma;
> > >      void *client;
> > >
> > >      DMAPushFn to_dma;
> > >      DMAPushFn to_client;
> > > };
> > >
> > > So what im proposing is AXI stream is implemented as a unidirectional
> > > point to point bus. The xilinx ethernet system would consist of two of
> > > these buses one for tx, one for rx.
> > >
> > > Onto the QOM stuff:
> > >
> > > Currently the DMA interconnect is handled as this struct I pasted
> > > above and a QDEV_PROP_PTR (which i understand is evil). The
> > > interconnect mechanism obviously needs to change. So lets assume that
> > > AXI stream is turned into a proper QEMU bus and devices can create
> > > sub-busses which they are the tx'ing master:
> > >
> > > s->axi_stream_master = axi_stream_create_bus(&dev->qdev, "axi_stream");
> > >
> > > Machine models can grab the bus to attach slaves:
> > >
> > > foo = qdev_get_child_bus(dev, "axi_stream");
> > >
> > > Where my thinking goes pear shaped though is having proper QOMified
> > > slaves. Each IP is a slave to both the sysbus and their respective
> > > rx'ing AXI stream bus. This is something of a multiple inheritance
> > > problem, I cant inherit from both SYSBUS and AXI_STREAM_SLAVE. So to
> > > overcome this should I ...
> > >
> > > A: Make AXI_STREAM_SLAVE an interface (not a sub-class of DEVICE). Its
> > > kind of annoying though if someone in the future whats the create a
> > > device thats only and axi stream slave, as they would have to
> > > explicitly inherit from DEVICE as well.
> > >
> > > or
> > >
> > > B: Have the slave attachment be a device within a device. Hard part is
> > > getting an accessor so machine models can retrieve the slave
> > > attachment and hook it up.
> > >
> > > Let me know what to do,
> > >
> > > Regards,
> > > Peter