Hi Valdis, I see. Thanks, I remember reading about the merits of virtual address in the books. 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 just want to make sure this is not a problem in my situtation. As I said earlier, in my case, during the init process, __nocache_fix(0xc8000000) is 0xc0540000. which is physically 0x60540000. Is this ok? could someone elaborate on this to me? Chan 보낸 사람 : "Valdis.Kletnieks@vt.edu" <Valdis.Kletnieks@vt.edu> 보낸 날짜 : 2014-05-19 22:12:08 ( +09:00 ) 받는 사람 : 김찬 <ckim@etri.re.kr> 참조 : kernelnewbies@kernelnewbies.org <kernelnewbies@kernelnewbies.org> 제목 : Re: two virtual address pointing to same physical address On Mon, 19 May 2014 11:47:23 -0000, Chan Kim said:

Is this situation normal? (in the kernel, two different virtual addresses pointing to the same physical address.)

Think for a bit how shared libraries are implemented. Then think about how mmap() of a shared region of a file at different virtual addresses in different processes works. Then you'll be able to answer your own question...

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.

FYI, I found out this morning, there is a SRMMU setting with initial page table before linux start_kernel starts. The page table directs 0xc0000000 to 0x60000000. Chan ________________________________ 보낸 사람 : "Chan Kim" <ckim@etri.re.kr> 보낸 날짜 : 2014-05-20 22:29:08 ( +09:00 ) 받는 사람 : Valdis.Kletnieks@vt.edu <Valdis.Kletnieks@vt.edu> 참조 : kernelnewbies@kernelnewbies.org <kernelnewbies@kernelnewbies.org> 제목 : Re: two virtual address pointing to same physical address 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" 보낸 날짜 : 2014-05-20 11:31:14 ( +09:00 ) 받는 사람 : 김찬 참조 : 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. _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies