| 116 | | To support this inter-cluster kernel-to-kernel communication, almos-mkh defines the ''remote_load( cxy , ptr )'' and ''remote_store( cxy , ptr ) functions, where ''ptr'' is a normal pointer (in kernel virtual space) on a variable stored in the KDATA vseg, and ''cxy'' is the remote cluster identifier. Notice that a given global variable is now identified by and extended pointer ''XPTR( cry , ptr )''. With these remote access primitives, any kernel instance in cluster K can access any global variable in any cluster. Notice that local accesses can use the normal pointers in virtual kernel space, as the virtual adresses will be simply translated by the MMU to the local physical address. |
| | 116 | To support this inter-cluster kernel-to-kernel communication, almos-mkh defines the ''hal_remote_load( cxy , ptr )'' and ''hal_remote_store( cxy , ptr ) functions, where ''ptr'' is a normal pointer (in kernel virtual space) on a variable stored in the KDATA vseg, and ''cxy'' is the remote cluster identifier. Notice that a given global variable is now identified by and extended pointer ''XPTR( cry , ptr )''. With these remote access primitives, any kernel instance in cluster K can access any global variable in any cluster. Notice that local accesses can use the normal pointers in virtual kernel space, as the virtual adresses will be simply translated by the MMU to the local physical address. |
| 139 | | The implementation of the remote access functions introduced in section 3 depends on the target architecture. |
| 140 | | |
| 141 | | |
| 142 | | rewant to communicate withA the writable and readable bi any functionin this vseg are identical in all clusters, and defined bbut this vseg being read/write, |
| 143 | | the contentglobal data. ALMOS-MK creates one DATA vseg in each vseg, that is registered in the reference VSL(P,KREF) when the process P is created in reference cluster KREF. In the other clusters K, the DATA vseg is registered in VSL(P,K) when a page fault is signaled by a thread of P running in cluster K. To avoid contention, this vseg is physically distributed on all clusters, with a page granularity. For each page, the physical mapping is defined by the LSB bits of the page VPN.* The read-only segment containing the user code is replicated in all clusters where there is at least one thread using it. |
| 144 | | |
| 145 | | |
| 146 | | The TSAR implementation is available in the [https://www-soc.lip6.fr/trac/almos-mkh/browser/trunk/hal/tsar_mips32/core/hal_remote.c almos_mkh/hal/tsar_mips32/core.hal_remote.c] file. |
| | 138 | The detailed implementation of the virtual to physical address translation depends on the target architecture. |
| 153 | | But the TSAR architecturethe MIPS32 core used BY the TSAR architecture HAS TWO NON STANDARDdefines another, non-standard, hardware mechanism to build a 40 bits physical address from a 32 bits virtual address. build an al |
| | 145 | But the TSAR architecture provides two non standard, but very useful features to simplify the virtual to physical address translation for kernel vsegs : |
| | 146 | 1. The TSAR 40 bits physical address has a specific format : it is the concaténation of an 8 bits CXY field, and a 32 bits LPADDR field, where the CXY defines |
| | 147 | the cluster identifier, and the LPADDR is the local physical address inside the cluster. |
| | 148 | 1. the MIPS32 core used BY the TSAR architecture defines, besides the standard MMU, another non-standard,hardware mechanism for address translation : A 40 bits physical address is simply build by appending to each 32 bits virtual address a 8 bits extension contained in a software controllable register, called DATA_PADDR_EXT. |
| 157 | | To enforce locality, there is one KDATA segment per cluster, containing a copy of all global variables statically allocated at compilation time. On the other hand, all structures dynamically allocated by the kernel (to create a new process descriptor, a new thread descriptor, a new file descriptor, etc.) are allocated in the KHEAP segment of the target cluster, and will be mainly handled by a kernel instance running in this same kernel. Therefore, most kernel memory accesses expected to be local. |
| | 152 | When the value contained in the extension register is the local cluster identifier, any local kernel structures stored in the KDATA or the KHEAP segments is accessed by using directly the local physical addresses (identity mapping). |
| | 153 | To access a remote kernel structure, almost-mkh '''must''' use the hardware architecture dependent remote access functions presented in section C. For the TSAR architecture these load/store functions simply modify the extension register DATA_PADDR_EXT before the memory access, and restore it after the memory access. |
| 161 | | |
| 162 | | |
| 163 | | In the TSAR architecture, and for any process P in any cluster K, almost-mkh registers only one extra KCODE vseg in the VMM[P,K), because almos-mkh does not use the DATA-MMU during kernel execution : Each time a core enters the kernel, to handle a sys call, an interrupt, or an exception, the DATA-MMU is deactivated, and It is reactivated when the core returns to user code. |
| 164 | | |
| 165 | | The architecture dependent [https://www-soc.lip6.fr/trac/almos-mkh/browser/trunk/hal/tsar/mips32/core/hal_remote.c remote access] functions use the TSAR specific extension register to build a 40 bits physical address from the 32 bits virtual address. |
| 166 | | |
| 167 | | This pseudo identity mapping impose some constraints on the KCODE vseg. |
| | 157 | The implementation of the hal_remote_load() and hal_remote_store() functions for the TSAR architecture is available in the [https://www-soc.lip6.fr/trac/almos-mkh/browser/trunk/hal/tsar_mips32/core/hal_remote.c almos_mkh/hal/tsar_mips32/core.hal_remote.c] file. |
