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

[Peter Crosthwaite]

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.

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.

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
>>
>