From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:50205) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SeNST-0001Mk-Ir for qemu-devel@nongnu.org; Tue, 12 Jun 2012 05:32:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SeNSO-00062f-KJ for qemu-devel@nongnu.org; Tue, 12 Jun 2012 05:32:17 -0400 Received: from mx1.redhat.com ([209.132.183.28]:49544) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SeNSO-00062B-CC for qemu-devel@nongnu.org; Tue, 12 Jun 2012 05:32:12 -0400 Message-ID: <4FD70C8E.9060703@redhat.com> Date: Tue, 12 Jun 2012 12:31:58 +0300 From: Avi Kivity MIME-Version: 1.0 References: <4FD208F6.3020307@codemonkey.ws> <4FD5EF75.7060707@us.ibm.com> <4FD60834.2020208@codemonkey.ws> <4FD62B5C.4040106@redhat.com> <4FD63A7F.8090902@codemonkey.ws> In-Reply-To: <4FD63A7F.8090902@codemonkey.ws> Content-Type: text/plain; charset=UTF-8 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: Anthony Liguori 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 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