From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:54629) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SeH4e-0004Eb-4T for qemu-devel@nongnu.org; Mon, 11 Jun 2012 22:43:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SeH4c-00032a-1y for qemu-devel@nongnu.org; Mon, 11 Jun 2012 22:43:15 -0400 Received: from gate.crashing.org ([63.228.1.57]:54725) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SeH4b-00031b-Ou for qemu-devel@nongnu.org; Mon, 11 Jun 2012 22:43:13 -0400 Message-ID: <1339468971.9220.61.camel@pasglop> From: Benjamin Herrenschmidt Date: Tue, 12 Jun 2012 12:42:51 +1000 In-Reply-To: <4FD695BA.80701@suse.de> 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> <4FD695BA.80701@suse.de> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 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: Andreas =?ISO-8859-1?Q?F=E4rber?= Cc: Peter Maydell , Anthony Liguori , "qemu-devel@nongnu.org Developers" , Peter Crosthwaite , Michal Simek , Avi Kivity , Anthony Liguori , "Edgar E. Iglesias" , John Williams , Paul Brook On Tue, 2012-06-12 at 03:04 +0200, Andreas F=C3=A4rber wrote: > 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. That can be considered as roughly equivalent for now, though it might become problematic when modelling crazy embedded setups, I think at this stage, we can consider that all the CPUs have the same view of the world which is more/less the "system bus". > 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=3Dbe2b26= 830deed1f728c01aa8f0582b63540919a8;hb=3DHEAD#l588 >=20 > 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? I think that's less urgent. The problem is really when going from that "system bus" down to various IO busses, whether they are AXI, PLB4/5/6, PCI or PCI behind any of the previous ones, etc.... There's potentially translation happening when crossing those bridges, though most of the time, this can be represented in the form of one or more "window" that forward a given region of the parent bus down to the child bus with an offset. >>From there, the child bus will itself potentially have a collection of stacked up bridges that may or may not translate or may or may not convey portions of that address space. The rules for translation "upstream" are similar, except that often you have an iommu on the way (though potentially there could be one on the way downstream as well). The "MemoryRegion" structure is a bit of an odd way to represent this but it could be re-used, though I reckon we should probably generalize the concept of "offset". Cheers, Ben.