[Top][All Lists]

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

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

From: Anthony Liguori
Subject: Re: [Qemu-devel] [RFC] QOMification of AXI stream
Date: Mon, 11 Jun 2012 08:15:33 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1

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

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.


Anthony Liguori


Of course, DMAContext could be made trivially into an Object and tx/rx could
be turned into link<>  properties.


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.


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,


reply via email to

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