RISC-V: detect virtual address space at runtime using hwprobe#1299
Conversation
|
Ah, I missed this PR and instead submitted review comments to 1296.. let me know what you prefer. |
Yes, I failed to properly close it #1296. I opened this one against dev3 (I haven't found at that time how to change the target branch on github). It doesn't make sense to use the dev branch as this doesn't exhibit the bug, and also fails to provide some functions such as I'll work on the changes you requested and update this PR. |
@daanx I have just done that, and rebased on the latest dev3 branch. |
The virtual address space on RISC-V is currently detected at build time by parsing /proc/cpuinfo. This works when the binary runs on the same hardware it was built, however running such a binary on a system with a larger address space just causes a segmentation fault. Replace the build time check with a runtime detection using the hwprobe interface (available since Linux 6.11, commit c9b8cd139c1d "riscv: hwprobe export highest virtual userspace address"), with a fallback to parsing /proc/cpuinfo on older kernels.
| file(STRINGS /proc/cpuinfo mi_sv57_mmu REGEX "^mmu[ \t]+:[ \t]+sv57$") | ||
| if (mi_sv39_mmu) | ||
| MESSAGE( STATUS "Set virtual address bits to 39 (SV39 MMU detected)" ) | ||
| list(APPEND mi_defines MI_DEFAULT_VIRTUAL_ADDRESS_BITS=39) |
There was a problem hiding this comment.
Does MI_DEFAULT_VIRTUAL_ADDRESS_BITS macro never been set for riscv ? I saw some code still use it, such as include/mimalloc/bits or src/os.c. Conditionally compiled _mi_page_map_init might suffered from this problem. Sorry if I'm wrong because the branches looks diverse a lot.
There was a problem hiding this comment.
Thanks @laokz -- it is safe since MI_DEFAULT_VIRTUAL_ADDRESS_BITS is just to override the default -- but runtime detection will take priority.
There was a problem hiding this comment.
Thanks for the reply. Yes, it has default value. I'm just curious is it really safe when _mi_page_map_init compiled as "2-level" version but running on sv39 machine, or vice versa. I saw the code has intent on the vabits :
// use a flat page-map or a 2-level one
#ifndef MI_PAGE_MAP_FLAT
#if MI_MAX_VABITS <= 40 && !defined(__APPLE__) && MI_SECURE==0 && !MI_PAGE_META_IS_SEPARATED
#define MI_PAGE_MAP_FLAT 1
#else
#define MI_PAGE_MAP_FLAT 0
#endif
#endif
|
Thank you! |
3 participants
The virtual address space on RISC-V is currently detected at build time by parsing /proc/cpuinfo. This works when the binary runs on the same hardware it was built, however running such a binary on a system with a larger address space just causes a segmentation fault.
Replace the build time check with a runtime detection using the hwprobe interface (available since Linux 6.11, commit c9b8cd139c1d "riscv: hwprobe export highest virtual userspace address"), with a fallback to parsing /proc/cpuinfo on older kernels.