Re: [Qemu-devel] Help - `flush_icache_range' MacPPC

[Alexander Graf]

On 09.02.2012, at 00:54, Scott Wood wrote:

> On 02/08/2012 05:42 PM, Alexander Graf wrote:
>> 
>> On 09.02.2012, at 00:29, Scott Wood wrote:
>> 
>>> On 02/07/2012 04:57 PM, Alexander Graf wrote:
>>>> Eh, this patch:
>>>> 
>>>> 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]);
>>>> }
>>>> 
>>>> +#ifdef __NetBSD__
>>>> +static void flush_icache_range(unsigned long begin, unsigned long end)
>>>> +{
>>>> +    unsigned int i = begin & ~15UL;
>>>> +    for (; i < end; i+=16) {
>>>> +        asm("icbi 0,%0" : : "r"(i));
>>>> +    }
>>>> +    asm("isync");
>>>> +}
>>>> +#endif
>>> 
>>> What about flushing the data cache first, as the other
>>> flush_icache_range does?
>> 
>> I actually wrote this one from scratch. Ahem.
>> 
>> 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.
> 
> 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 ;).

> 
>>> 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?
>> 
>> Oh, there is a cache flush function already there! Hah! I completely missed 
>> out on that one.
>> 
>> 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.
> 
> 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