From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:48403) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Se9Sx-0003vf-Md for qemu-devel@nongnu.org; Mon, 11 Jun 2012 14:35:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Se9Sv-00035r-B1 for qemu-devel@nongnu.org; Mon, 11 Jun 2012 14:35:51 -0400 Received: from mail-pz0-f45.google.com ([209.85.210.45]:58792) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Se9Sv-000355-4I for qemu-devel@nongnu.org; Mon, 11 Jun 2012 14:35:49 -0400 Received: by dadv2 with SMTP id v2so6345543dad.4 for ; Mon, 11 Jun 2012 11:35:47 -0700 (PDT) Message-ID: <4FD63A7F.8090902@codemonkey.ws> Date: Mon, 11 Jun 2012 13:35:43 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <4FD208F6.3020307@codemonkey.ws> <4FD5EF75.7060707@us.ibm.com> <4FD60834.2020208@codemonkey.ws> <4FD62B5C.4040106@redhat.com> In-Reply-To: <4FD62B5C.4040106@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] QOMification of AXI stream List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Peter Maydell , Anthony Liguori , Michal Simek , "qemu-devel@nongnu.org Developers" , Peter Crosthwaite , Paul Brook , "Edgar E. Iglesias" , =?UTF-8?B?QW5kcmVhcyBGw6Q=?= =?UTF-8?B?cmJlcg==?= , John Williams On 06/11/2012 12:31 PM, Avi Kivity wrote: > On 06/11/2012 06:01 PM, Anthony Liguori wrote: >> On 06/11/2012 08:39 AM, Peter Maydell wrote: >>> On 11 June 2012 14:15, Anthony Liguori wrote: >>>> 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. >>> >>> ...so can we fix the name? >> >> Perhaps we should just make MemoryRegion work in both directions? >> >> Ben/Avi, what do you guys think? >> > > 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. > 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. My biggest worry is that we'll end up with parallel memory API implementations split between memory.c and dma.c. Regards, Anthony Liguori >