Re: Fw: ia64: race flushing icache in do_no_page path

Rohit Seth wrote:
>  
> 
> -----Original Message-----
> From: Hugh Dickins [mailto:hughveritas.com] 
> Sent: Friday, April 27, 2007 10:20 PM
> To: Nick Piggin
> Cc: rohitsethgoogle.com; Mike Stroyan; Andrew Morton;
Luck, Tony;
> linux-ia64vger.kernel.org; linux-kernelvger.kernel.org
> Subject: Re: Fw: [PATCH] ia64: race flushing icache in
do_no_page path
> 
> On Sat, 28 Apr 2007, Nick Piggin wrote:
> 
>>OIC, you need a virtual address to evict the icache,
so you can't 
>>flush at flush_dcache time? Or does ia64 have an
instruction to flush 
>>the whole icache? (it would be worth testing, to see
how much 
>>performance suffers).
> 
> 
> IIRC, there is a PAL call to flush the whole cache (but
that is quite a
> heavy call).  Though you really don't need to be doing
this.
> 
> 
>>I'm puzzled by that remark: the ia64
flush_icache_range always has a 
>>virtual address, it uses the kernel virtual address;
it takes 
>>no interest in whether there's a user virtual
address.
> 
> 
> Caches on Itanium are physical.  So, it doesn't matter
what virtual address
> you use to flush a cache line, cache line containing
specific physical
> memory will be flushed. 

Really? I was under the vague impression that L1 i/d caches
were virtual
and required this flushing... but I guess so long as the ISA
says that
fc/fc.i flushes all caches corresponding to the physical
address of the
provided virtual address, then that's what matters.

> For the cases where you have virtual caches,
> update_mmu_cache is the API to use.

But it happens after the pte is installed.

-- 
SUSE Labs, Novell Inc.
-
To unsubscribe from this list: send the line
"unsubscribe linux-ia64" in
the body of a message to majordomovger.kernel.org
More majordomo info at  http://vge
r.kernel.org/majordomo-info.html

On Tue, May 01, 2007 at 09:43:29PM +1000, Nick Piggin
wrote:
> Rohit Seth wrote:
...
> >Caches on Itanium are physical.  So, it doesn't
matter what virtual address
> >you use to flush a cache line, cache line
containing specific physical
> >memory will be flushed. 
> 
> Really? I was under the vague impression that L1 i/d
caches were virtual
> and required this flushing... but I guess so long as
the ISA says that
> fc/fc.i flushes all caches corresponding to the
physical address of the
> provided virtual address, then that's what matters.

  The L1 caches on Itanium have interesting behavior.  The
cache lines
are indexed by virtual address.  But those L1 cache lines
are invalidated
whenever their corresponding L1 TLB entry is evicted or
replaced.
That means that old L1 icache lines will be invalidated by
TLB changes
even before a fc.i instruction flushed those icache lines. 
That would
help make old kernels work on pre-montecito processors
without correctly
ordered fc.i instructions.  The L1 icache was flushed by TLB
inserts
and the L2 icache was unified.

  fc.i is also defined to make an address coherent between
data and
instruction caches at all levels of cache.  That handles the
update of
L1 icache lines during a st,fc.i,sync.i,srlz.i sequence.

  I see these details in section 6.1.1 of "IntelŪ
ItaniumŪ 2 Processor
Reference Manual".  But I haven't found them in a
general Itanium
Architecture reference.

-- 
Mike Stroyan, mike.stroyanhp.com
-
To unsubscribe from this list: send the line
"unsubscribe linux-ia64" in
the body of a message to majordomovger.kernel.org
More majordomo info at  http://vge
r.kernel.org/majordomo-info.html