[Top][All Lists]

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

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

From: Avi Kivity
Subject: Re: [Qemu-devel] [RFC] QOMification of AXI stream
Date: Tue, 12 Jun 2012 12:31:58 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120605 Thunderbird/13.0

On 06/11/2012 09:35 PM, Anthony Liguori wrote:
>> The other direction is currently cpu_physical_memory_rw().
> Right, and with benh's proposal, it's dma_memory_rw().  It also adds a
> DMAContext parameter.
> I can't help think that the contents of DMAContext is awfully similar to
> MemoryRegionOps.
>>  We do need
>> to support issuing transactions from arbitrary points in the memory
>> hierarchy, but I don't think a device's MemoryRegion is the right
>> interface.  Being able to respond to memory transactions, and being able
>> to issue them are two different things.
> But an IOMMU has to be able to respond to a memory transaction.  Many of
> the things it may do (like endianness conversion) also happen to already
> exist in the memory API.

Right; it's both an initiator and a target.  We'll need something for
initiators, we have MemoryRegion for targets, and iommus will use both.

>> In fact we will probably have to add more details to the memory
>> hierarchy.  Currently (for example) we model the memory hub passing
>> transactions destined for the various pci windows to the pci bus, but we
>> don't model the memory hub receiving a pci-initiated transaction and
>> passing it to the system bus.  We simply pretend it originated on the
>> system bus in the first place.  Perhaps we need parallel hierarchies:
>>     system_memory
>>        alias ->  pci
>>        alias ->  ram
>>     pci
>>        bar1
>>        bar2
>>     pcibm
>>        alias ->  pci  (prio 1)
>>        alias ->  system_memory (prio 0)
>> cpu_physical_memory_rw() would be implemented as
>> memory_region_rw(system_memory, ...) while pci_dma_rw() would be
>> implemented as memory_region_rw(pcibm, ...).  This would allow different
>> address transformations for the two accesses.
> Yeah, this is what I'm basically thinking although I don't quite
> understand what 'pcibm' stands for.

PCI bus master

> My biggest worry is that we'll end up with parallel memory API
> implementations split between memory.c and dma.c.

It definitely belongs together.

error compiling committee.c: too many arguments to function

reply via email to

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