From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:44313) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SeNcE-0004nF-IU for qemu-devel@nongnu.org; Tue, 12 Jun 2012 05:42:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SeNc8-0002OW-1t for qemu-devel@nongnu.org; Tue, 12 Jun 2012 05:42:22 -0400 Received: from mail-lpp01m010-f45.google.com ([209.85.215.45]:35495) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SeNc7-0002Nh-Nv for qemu-devel@nongnu.org; Tue, 12 Jun 2012 05:42:15 -0400 Received: by lahc1 with SMTP id c1so3773409lah.4 for ; Tue, 12 Jun 2012 02:42:13 -0700 (PDT) Date: Tue, 12 Jun 2012 11:42:09 +0200 From: "Edgar E. Iglesias" Message-ID: <20120612094209.GB14313@edde.se.axis.com> References: <4FD208F6.3020307@codemonkey.ws> <4FD5EF75.7060707@us.ibm.com> <4FD60834.2020208@codemonkey.ws> <4FD62B5C.4040106@redhat.com> <4FD63A7F.8090902@codemonkey.ws> <4FD70C8E.9060703@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FD70C8E.9060703@redhat.com> 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 , Anthony Liguori , Andreas =?iso-8859-1?Q?F=E4rber?= , John Williams On Tue, Jun 12, 2012 at 12:31:58PM +0300, Avi Kivity wrote: > 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. I agree. Would be good to keep DMA out of the naming. It's just about adding support for multiple initiators/masters (DMA is just one of the use-cases).. Cheers, Edgar