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@vt.edu" <Valdis.Kletnieks@vt.edu> 보낸 날짜 : 2014-05-20 11:31:14 ( +09:00 ) 받는 사람 : 김찬 <ckim@etri.re.kr> 참조 : kernelnewbies@kernelnewbies.org <kernelnewbies@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.