From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:47993) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RvHPW-00082z-Gm for qemu-devel@nongnu.org; Wed, 08 Feb 2012 18:58:51 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RvHPR-00083y-1c for qemu-devel@nongnu.org; Wed, 08 Feb 2012 18:58:50 -0500 Received: from cantor2.suse.de ([195.135.220.15]:38148 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RvHPQ-00083s-P8 for qemu-devel@nongnu.org; Wed, 08 Feb 2012 18:58:45 -0500 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Alexander Graf In-Reply-To: <4F330B39.5050609@freescale.com> Date: Thu, 9 Feb 2012 00:58:42 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6802A6BA-DD4F-434D-B876-0332147F1A9E@suse.de> References: <20120207125222.111560@gmx.net> <443210D1-C948-435B-9C58-D4E989591BC5@suse.de> <4F31A5E6.2090802@comstyle.com> <4F330575.1020407@freescale.com> <6904B6A7-A433-4661-BDB6-A9803F666F6D@suse.de> <4F330B39.5050609@freescale.com> Subject: Re: [Qemu-devel] Help - `flush_icache_range' MacPPC List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Scott Wood Cc: Maurizio Caloro , qemu-devel@nongnu.org, Brad Smith On 09.02.2012, at 00:54, Scott Wood wrote: > On 02/08/2012 05:42 PM, Alexander Graf wrote: >>=20 >> On 09.02.2012, at 00:29, Scott Wood wrote: >>=20 >>> On 02/07/2012 04:57 PM, Alexander Graf wrote: >>>> Eh, this patch: >>>>=20 >>>> diff --git a/tcg/ppc/tcg-target.c b/tcg/ppc/tcg-target.c >>>> index f5d9bf3..f9793e6 100644 >>>> --- a/tcg/ppc/tcg-target.c >>>> +++ b/tcg/ppc/tcg-target.c >>>> @@ -1260,6 +1260,17 @@ static void tcg_out_brcond2 (TCGContext *s, = const TCGArg *args, >>>> tcg_out_bc (s, (BC | BI (7, CR_EQ) | BO_COND_TRUE), args[5]); >>>> } >>>>=20 >>>> +#ifdef __NetBSD__ >>>> +static void flush_icache_range(unsigned long begin, unsigned long = end) >>>> +{ >>>> + unsigned int i =3D begin & ~15UL; >>>> + for (; i < end; i+=3D16) { >>>> + asm("icbi 0,%0" : : "r"(i)); >>>> + } >>>> + asm("isync"); >>>> +} >>>> +#endif >>>=20 >>> What about flushing the data cache first, as the other >>> flush_icache_range does? >>=20 >> I actually wrote this one from scratch. Ahem. >>=20 >> So why are we flushing the dcache on the other one? Does the icache >> always fill from memory or can it check if something's in the dcache >> and fetch it from there? If it's the former, then a dcache flush is >> crucial, right. >=20 > The icache is allowed to fill directly from memory, without snooping > dcache. Where it actually fetches from and whether it snoops any data > cache is implementation-dependent. On our implementations, = instruction > fetches do not snoop data cache. The fetch could hit in main memory, = or > in a shared cache such as L3/CPC (e500mc) or L2 (e500v2). I see. Then the implementation we have seems to do the right thing ;). >=20 >>> Why isn't the cache-utils.h version of flush_icache_range being = seen? >>> It's only ppc_init_cacheline_sizes() that is OS-conditional -- = shouldn't >>> that be what the undefined reference is for? Is _ARCH_PPC failing = to be >>> defined? >>=20 >> Oh, there is a cache flush function already there! Hah! I completely = missed out on that one. >>=20 >> I would assume it's either because _ARCH_PPC is failing to be picked >> up (include order?) or because the header file is just not included. >> My motivation in digging into ppc NetBSD issues is rather small >> though. >=20 > It looks like GCC sets _ARCH_PPC. Apparently this isn't happening on > this user's toolchain. Broken NetBSD again :). I don't think we have to worry too much about it = for now. As long as this is documented on the mailing list (which it is = now) someone who cares about NetBSD can either a) fix their toolchain or b) add a patch to match on something different and then the 2 other people on this planet running NetBSD PPC will be = happy :) Alex