[Top][All Lists]

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

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

From: Peter Crosthwaite
Subject: Re: [Qemu-devel] [RFC] QOMification of AXI stream
Date: Sat, 9 Jun 2012 11:24:26 +1000

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

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.


> 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

reply via email to

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