From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:56131) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sf0Yu-00011F-BR for qemu-devel@nongnu.org; Wed, 13 Jun 2012 23:17:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sf0Ys-00061Y-DC for qemu-devel@nongnu.org; Wed, 13 Jun 2012 23:17:31 -0400 Received: from mail-bk0-f45.google.com ([209.85.214.45]:33264) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sf0Ys-00061D-46 for qemu-devel@nongnu.org; Wed, 13 Jun 2012 23:17:30 -0400 Received: by bkwj10 with SMTP id j10so1109584bkw.4 for ; Wed, 13 Jun 2012 20:17:28 -0700 (PDT) Date: Thu, 14 Jun 2012 05:17:23 +0200 From: "Edgar E. Iglesias" Message-ID: <20120614031723.GC29384@zapo> References: <1339452058.9220.32.camel@pasglop> <4FD67132.1060001@codemonkey.ws> <4FD7100F.3080207@redhat.com> <1339547861.9220.77.camel@pasglop> <20120614000001.GA26263@zapo> <1339637650.9220.134.camel@pasglop> <20120614020306.GA29384@zapo> <1339640205.9220.139.camel@pasglop> <20120614023154.GB29384@zapo> <1339641666.9220.146.camel@pasglop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1339641666.9220.146.camel@pasglop> Subject: Re: [Qemu-devel] [RFC] QOMification of AXI streams List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Benjamin Herrenschmidt Cc: Peter Maydell , Anthony Liguori , "qemu-devel@nongnu.org Developers" , Peter Crosthwaite , Michal Simek , Avi Kivity , Anthony Liguori , Andreas =?iso-8859-1?Q?F=E4rber?= , John Williams , Paul Brook On Thu, Jun 14, 2012 at 12:41:06PM +1000, Benjamin Herrenschmidt wrote: > On Thu, 2012-06-14 at 04:31 +0200, Edgar E. Iglesias wrote: > > > An AXI device might issue a cycle on the AXI portion, that can be > > > decoded by either a sibling AXI device ... or go up. In most cases > > > > No, it doesn't really go up.. This is where we disagree. > > Well, not really indeed as the memory subsystem is just another sibling > in this specific case, bad choice of words here. Though it does go "up" > in a way if you are in a cache coherent system thanks to snooping :-) > But right, memory is just a sibling. > > > > though, "upstream" is some kind of substractive decoding (ie. anything > > > -not- decoded by a sibling goes up). > > > > I've never seen this happen, but I won't say it doesn't exist because > > you'll find all kinds of HW out there that'll do all kind of stuff > > you wouldn't imagine. > > Its quite common. You seem to have a vision limited to a single flat bus > with all the devices connected to it :-) The minute you start having bus > hierarchies things become much more interesting... Even on ARM, with PCI > for example. I probably have a limited view, but I've worked with developing devices and connecting them to various busses for a while so I'm not completely lost. > > > > This gets even more obvious with PCI of course. Then add a b43 wifi card > > > on PCI, you have AXI -> PCI -> SSB (silicon backplane). Now what happens > > > when one of the sub-devices on SBB (the MAC interface for example) does > > > a bus master ? You have at least 2 layers to cross before you hit your > > > processor bus. > > > > > > Add iommu's to the soup and you get into a serious mess :-) > > > > IOmmus messify things a bit, but the translation is only done from > > the masters above the iommu going down theough the iommu. Not > > vice versa. At least AFAIK. > > Sure, for the very simple reason that the iommu typically sits behind > the master. So the other direction is handled by the CPU's MMU. The CPU's MMU is a CPU local thing, it can be ignored in this context... Anyway, I might very well be missing or missunderstganding something so I'm not claiming I'm having the absolute "thruth" here but it seems to me like implementing device accesses bottom-up or "upstream", is something that is extremely rare (to put it mildely), something that is unnecessary unless we __really__ need it. Cheers