[Linux-ia64] Modifing memory attributes needs cache flush

[Linux-ia64] Modifing memory attributes needs cache flush

[Takanori Kawano]

It noticed current ia64 code doesn't flush any processor 
cache before modifing memory attributes, though the following 
description in SDM vol2 Section4.4.2 says it should be done.

 If software modifies the memory attributes for a page, software must flush
 any processor cache copies with the Flush Cache(fc) instruction for the 
 following memory attribute changes:
 speculative/non-speculative, cacheable/uncacheable(for transitions from 
 cacheable to uncacheable), and coherency. Software must flush any coalescing 
 buffers if a page is changes from coalescing to any other attribute.
 

Does anybody know why the current code doesn't flush cache?

I have some problem that seems to be caused by the ansence 
of cache flush and I am writing a patch fixes it, so I'll
appreciate any information about it.

---
Takanori Kawano
Hitachi Ltd,
Internet Systems Platform Division
t-kawano@ebina.hitachi.co.jp

Re: [Linux-ia64] Modifing memory attributes needs cache flush

[David Mosberger]

>>>>> On Wed, 09 Jan 2002 17:39:38 +0900 (JST), Takanori Kawano <t-kawano@ebina.hitachi.co.jp> said:

  Takanori>  If software modifies the memory attributes for a page,
  Takanori> software must flush any processor cache copies with the
  Takanori> Flush Cache(fc) instruction for the following memory
  Takanori> attribute changes: speculative/non-speculative,
  Takanori> cacheable/uncacheable(for transitions from cacheable to
  Takanori> uncacheable), and coherency. Software must flush any
  Takanori> coalescing buffers if a page is changes from coalescing to
  Takanori> any other attribute.

  Takanori> Does anybody know why the current code doesn't flush
  Takanori> cache?

Well, the kernel is supposed to use each page in a consistent fashion
(no change of attributes).  Though this isn't enforced anywhere (see
earlier discussion about write-coalescing mappings.  We need a general
solution for this eventually.  For now, it will have to be dealt with
on a case-by-case basis, I think.

	--david