From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:48968) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Se9U5-00054j-M7 for qemu-devel@nongnu.org; Mon, 11 Jun 2012 14:37:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Se9U3-0003bp-SD for qemu-devel@nongnu.org; Mon, 11 Jun 2012 14:37:01 -0400 Received: from mail-pb0-f45.google.com ([209.85.160.45]:38666) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Se9U3-0003aE-Gj for qemu-devel@nongnu.org; Mon, 11 Jun 2012 14:36:59 -0400 Received: by pbbro12 with SMTP id ro12so6546856pbb.4 for ; Mon, 11 Jun 2012 11:36:57 -0700 (PDT) Message-ID: <4FD63AC6.3070608@codemonkey.ws> Date: Mon, 11 Jun 2012 13:36:54 -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(). 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. > > 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. BTW, the main problem with the memory API right now is that there isn't a 'MemoryRegion *mr' as the first argument to the dispatch functions. This could be fixed by introducing yet another set of function pointers and keeping the existing callers unchanged though. Regards, Anthony Liguori > >