You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We could add simple wrappers such as microkit_arm_cache_clean and microkit_arm_cache_invalidate and so on, these would simply abstract away the VSpace cap since it's fixed.
However, I believe the default seL4 configurations for AArch64 also allow users to do some of these operations from user-space. Should these microkit_arm_cache_* APIs only call the system call if caching operations from user-space are not enabled? Are there any issues with this indirection? Should we be simple and only supply the system call wrappers and leave it to users to decide what to do?
It certainly leads to better performance.
The text was updated successfully, but these errors were encountered:
There is currently no API for doing cache operations on ARM platforms. This leads to code like this
microkit/example/tqma8xqp1gb/ethernet/eth.c
Line 609 in 71e0144
which should not be necessary.
We could add simple wrappers such as
microkit_arm_cache_clean
andmicrokit_arm_cache_invalidate
and so on, these would simply abstract away the VSpace cap since it's fixed.However, I believe the default seL4 configurations for AArch64 also allow users to do some of these operations from user-space. Should these
microkit_arm_cache_*
APIs only call the system call if caching operations from user-space are not enabled? Are there any issues with this indirection? Should we be simple and only supply the system call wrappers and leave it to users to decide what to do?It certainly leads to better performance.
The text was updated successfully, but these errors were encountered: