Hi Daniel, The convention is: - paddr_t is used for physical addresses. - pptr_t is a virtual address "in the kernel window" that refers to a kernel object (e.g. page directory or endpoint). Users don't have access to any pptr_t addresses (but might have a capability to do operations on it, via syscalls). - vptr_t is a virtual address in user-space but not in the kernel window. Usually, this is calculated when doing operations on user-level address space (i.e. mapping a page at vptr_t, or invalidate a "user-level" Cache/TLB entry). Hope that helps. On 01/04/17 06:37, Daniel (Xiaolong) Wang wrote:

Hi all,

I have a probably a dumb question that need some clarification. I was reading the kernel source code and I’m little bit confused with the three data type:

*paddr_t*, *pptr_t*, *vptr_t *and the following three data struct related to them. * * *typedef struct region {* * pptr_t start;* * pptr_t end;* *} region_t;* * * *typedef struct p_region {* * paddr_t start;* * paddr_t end;* *} p_region_t;* * * *typedef struct v_region {* * vptr_t start;* * vptr_t end;* *} v_region_t;*

Based on how those are being used I assume the *paddr_t *and* p_region *are data struct for physical address, *vptr_t* and *v_region *are for virtual address. According to the following functions seem that the translation between physical address to pptr_r is by adding/subtracting a offset. But I’m confused with the *pptr_t* and region I wonder what are those for? Tank you very much!

/static inline void* CONST/ /ptrFromPAddr(paddr_t paddr)/ /{/ / return (void*)(paddr + physMappingOffset);/ /}/ / / /static inline paddr_t CONST/ /addrFromPPtr(void* pptr)/ /{/ / return (paddr_t)pptr - physMappingOffset;/ /}/ / / /static inline region_t CONST/ /paddr_to_pptr_reg(p_region_t p_reg)/ /{/ / return (region_t) {/ / p_reg.start + physMappingOffset, p_reg.end + physMappingOffset/ / };/ /}/ / / /static inline p_region_t CONST/ /pptr_to_paddr_reg(region_t reg)/ /{/ / return (p_region_t) {/ / reg.start - physMappingOffset, reg.end - physMappingOffset/ / };/ /}/

Thanks -Dan

_______________________________________________ Devel mailing list Devel@sel4.systems https://sel4.systems/lists/listinfo/devel

-- Hesham Almatary Kernel Engineer DATA61 | CSIRO E: hesham.almatary@csiro.au www.data61.csiro.au