From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:58851) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SeQzJ-0001T8-Eh for qemu-devel@nongnu.org; Tue, 12 Jun 2012 09:18:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SeQzE-0008O8-Da for qemu-devel@nongnu.org; Tue, 12 Jun 2012 09:18:24 -0400 Received: from mx1.redhat.com ([209.132.183.28]:54031) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SeQzE-0008N7-5j for qemu-devel@nongnu.org; Tue, 12 Jun 2012 09:18:20 -0400 Message-ID: <4FD7418E.9080808@redhat.com> Date: Tue, 12 Jun 2012 16:18:06 +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> In-Reply-To: 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: Peter Maydell Cc: Anthony Liguori , Michal Simek , "qemu-devel@nongnu.org Developers" , Peter Crosthwaite , Paul Brook , Anthony Liguori , "Edgar E. Iglesias" , =?UTF-8?B?QW5kcmVhcyBGw6Q=?= =?UTF-8?B?cmJlcg==?= , John Williams On 06/12/2012 03:58 PM, Peter Maydell wrote: > On 11 June 2012 18:31, Avi Kivity wrote: >> On 06/11/2012 06:01 PM, Anthony Liguori wrote: >>> Perhaps we should just make MemoryRegion work in both directions? > >> 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. > > ...they're just opposite sides of the same interface, though, > really. For instance you could say that any memory transaction > master (cpu, dma controller, whatever) should take a single > MemoryRegion* and must issue all its memory accesses to that MR*. > (obviously that would usually be a container region.) It would be a container region, and it would be unrelated to any other regions held by the device (the device might not have any memory regions; instead it would only be able to do dma). > >> 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. > > Ideally system_memory shouldn't exist at all. Anything > which can issue transactions should do it by exposing > a suitable interface which the system model can then > just wire up suitably. Obviously mostly that's going > to be "all these devices go here in the memory map and > that view of the world is what all the CPUs see", but > we shouldn't have a globally accessible and implicitly > used address space IMHO. > > (For instance, the right way to model per-CPU devices > is to have each individual CPU core expose its transaction > master, and then you wire the per-CPU devices up only > to their corresponding CPU.) Correct. system_memory would be renamed cpu_memory, and would be cpu local (since some systems allow each cpu to have a different memory map). phys_map would be a cache for the memory map that can be seen through that region; we might make it a field of MemoryRegion. -- error compiling committee.c: too many arguments to function