From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:36964) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SeFXj-0001FN-7W for qemu-devel@nongnu.org; Mon, 11 Jun 2012 21:05:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SeFXg-0008DA-GB for qemu-devel@nongnu.org; Mon, 11 Jun 2012 21:05:10 -0400 Received: from cantor2.suse.de ([195.135.220.15]:43803 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SeFXg-0008Ae-7x for qemu-devel@nongnu.org; Mon, 11 Jun 2012 21:05:08 -0400 Message-ID: <4FD695BA.80701@suse.de> Date: Tue, 12 Jun 2012 03:04:58 +0200 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= 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> <1339452058.9220.32.camel@pasglop> In-Reply-To: <1339452058.9220.32.camel@pasglop> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC] QOMification of AXI streams List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Benjamin Herrenschmidt , Avi Kivity Cc: Peter Maydell , Anthony Liguori , Michal Simek , "qemu-devel@nongnu.org Developers" , Peter Crosthwaite , Paul Brook , Anthony Liguori , "Edgar E. Iglesias" , John Williams Am 12.06.2012 00:00, schrieb Benjamin Herrenschmidt: >>> 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 allo >> 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. >=20 > So it makes some amount of sense to use the same structure. For example= , > if a device issues accesses, those could be caught by a sibling device > memory region... or go upstream. >=20 > Let's just look at downstream transformation for a minute... >=20 > We do need to be a bit careful about transformation here: I need to > double check but I don't think we do transformation downstream today in > a clean way and we'd have to do that. IE. On pseries for example, the > PCI host bridge has a window in the CPU address space of [A...A+S], but [snip] That's not quite the way we're modelling it yet as shown by Avi above, there is no CPU address space, only a "system" address space. The way we're modelling it today is shoving everything into a global machine-level adress space which many devices access themselves via get_system_memory() and get_system_io() because there's no easy way to pass it to them except for exposing their struct and setting a field before qdev_init_nofail(). http://git.qemu.org/?p=3Dqemu.git;a=3Dblob;f=3Dhw/ppc_prep.c;h=3Dbe2b2683= 0deed1f728c01aa8f0582b63540919a8;hb=3DHEAD#l588 Can't each CPUState get a MemoryRegion for its CPU address space, which then can have subregions/aliases for the one system_memory with its subregions for PCI host bridge etc.? Then there's no need any more to have a cpu_physical_memory_rw(), is there? Cheers, Andreas --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=C3=B6rffer; HRB 16746 AG N=C3=BC= rnberg