From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:57679) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S7kBj-0002op-EY for qemu-devel@nongnu.org; Wed, 14 Mar 2012 05:08:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S7kBa-0002Y0-JK for qemu-devel@nongnu.org; Wed, 14 Mar 2012 05:08:07 -0400 Received: from ozlabs.org ([203.10.76.45]:45797) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S7kBZ-0002Wv-V8 for qemu-devel@nongnu.org; Wed, 14 Mar 2012 05:07:58 -0400 Date: Wed, 14 Mar 2012 20:05:23 +1100 From: David Gibson Message-ID: <20120314090523.GW24916@truffala.fritz.box> References: <1331269308-22372-1-git-send-email-david@gibson.dropbear.id.au> <1331269308-22372-11-git-send-email-david@gibson.dropbear.id.au> <4F59DA05.40204@redhat.com> <20120313050734.GL24916@truffala.fritz.box> <78EB34FD-B41C-4D40-B05D-0BDB070EA6AA@suse.de> <20120313140430.GS24916@truffala.fritz.box> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [PATCH 10/13] iommu: Introduce IOMMU emulation infrastructure List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: Paolo Bonzini , mst@redhat.com, eduard.munteanu@linux360.ro, qemu-devel@nongnu.org, rth@twiddle.net On Tue, Mar 13, 2012 at 03:37:09PM +0100, Alexander Graf wrote: > On 13.03.2012, at 15:04, David Gibson wrote: > > On Tue, Mar 13, 2012 at 02:56:47PM +0100, Alexander Graf wrote: > >> On 13.03.2012, at 06:07, David Gibson wrote: [snip] > >>>> This need not be a configure option. Just enable it, or it will > >>>> bitrot. > >>> > >>> I did wonder about that. I'd like to hear that suggested by more than > >>> one person before I unconditionally add code which will impose an > >>> overhead on all emulated DMAs. > >> > >> Maybe make it a target option? That way targets that want and need > >> an IOMMU can compile the code in, while the others don't see > >> performance hits. That would of course mean that we'd still have > >> conditional code paths, but at least they wouldn't bitrot, as > >> building multiple targets means you'd build both paths. > > > > Heh, yeah, so I tried that way back. It's problematic, unfortunately, > > as it would require pulling a number of things out of libhw and back > > into target dependent code. > > Hrm. How about measuring the performance overhead then? Maybe it's > negligible? Yeah, I should do that. Finding a suitable testcase and running it on a variety of targets is non-trivial, though. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson