two virtual address pointing to same physical address

[Chan Kim]

Valdis and all,
I understand we cannot access the same physical memory both as cacheable and non-cacheable.
and I'm pretty sure they were pointing to the same physical address. (I haven't check with mmap yet, I will try later.)
The point I was confused about was the __nocache_fix operation to the address.
Writing a reply email, I remembered that the __nocache_fix conversion to the address is used only before MMU setup.
After MMU setup (setting the context table and PGD pointer to the MMU register), the __nocache_fix operation to the address is not used.
but __nocache_fix(0xc8000320) is 0xc0540320 and In our system we don't have physical memory at 0xc0000000 ~. 
(we have memory at 0x60000000 ~ 0x6fffffff)
seeing the definition of __nocache_fix, the input and ouput is all virtual address (VADDR). 
This means I can access virtual address 0xc054xxxx (nocache region) through MMU to 0x6054xxxx.
Maybe before the MMU setup, somewhere at a previous point, the 0xc054.... -> 0x6054...  virtual->physical conversion may have been setup to the SRMMU. I have to check. (in the prom_stage, or very early in the init)
Can anybody give me some light on this?
Thanks,
Chan



보낸 사람 : "Valdis.Kletnieks at vt.edu" <Valdis.Kletnieks at vt.edu>
보낸 날짜 : 2014-05-20 11:31:14 ( +09:00 )
받는 사람 : 김찬 <ckim at etri.re.kr>
참조 : kernelnewbies at kernelnewbies.org <kernelnewbies at kernelnewbies.org>
제목 : Re: two virtual address pointing to same physical address

On Tue, 20 May 2014 00:39:26 -0000, Chan Kim said:
> But still it's confusing. Can two virtual addresses from the "same process"
> (in init process, one for nocache pool, the other not) point to the same
> physical address?

I'm not sure what you're trying to say there. In general, the hardware
tags like non-cacheable and write-combining are applied to physical addresses,
not virtual.

And a moment's thought will show that treating the same address (whether it's
virtual or physical) as caching in one place and non-caching in another is just
*asking* for a stale-data bug when the non-caching reference updates data and
the caching reference thinks it's OK to use the non-flushed non-refreshed
cached data.

It's easy enough to test if two addresses from a single process can
point to the same physical address - do something like this:

/* just ensure these two map the same thing at different addresses */
foo = mmap(something,yaddayadda);
bar = mmap(something,yaddayadda);
/* modify via one reference */
*foo = 23;
/* you probably want a barrier call here so gcc doesn't screw you */
/* Now dereference it via the other reference */
printf("And what we read back is %d\n", *bar);

(Making this work is left as an exercise for the student :)

And figuring out why you need a barrier is fundamental to writing bug-free
code that uses shared memory. The file Documentation/memory-barriers.txt
is a good place to start.