Ignatios Souvatzis wrote:

> 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.

Yes, which means taking the relevant data out of the D-cache and then
clearing the I-cache.

> - 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?

Yes.

> 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)

Basically, make the call do a cpu_cache_purgeID_rng() or something
similar, and then everything should be funky. There might have been a
syncI call which could do the job, but I can't remember if that knocked
out the entire d-cache first.

	Regards,

	Neil

-- 
Neil A. Carson