Subject: ARM caches
To: None <port-arm32@netbsd.org>
From: Ignatios Souvatzis <is@jocelyn.rhein.de>
List: port-arm32
Date: 02/26/1999 21:01:02
Hello,

I tried to understand how StrongARMs and our kernel work wrt. caches. 

Let me summarize, and correct me if I'm wrong:

- both I and D caches are virtual. (If available)
- At context switch time, we flush the user addresses from the caches.

As a result:
- if a process modifies itself, or a kernel modifies curproc, it has to 
  do I-cache syncing.

- if a process or the kernel modifies a process != curproc, it doesn't
  have to do extra work besides what would happen at the next context switch
  making it active.

Is this right?

The reason I'm asking is that I looked at the relevant code and at StrongARM
documentation, trying to understand what pmap_procwr would need to do on 
arm32. (And I tried setting a breakpoint from gdb, and it worked.)

It looks to me that it would do a

/****/
if (p != curproc)
	return;
call_the_available_icache_sync_code();
/****/

Yes, so its not relevant for gdb, but somebody might be find a reason
to manipulate its own address space through procfs instead of directly.

For the background, look at tech-kern, thread 
 PR 6152 (gdb fails on UVM for seperate I&D), and fix (ATTN portmasters


Regards,
	Ignatios