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?
There is currently no API for doing cache operations on ARM platforms. This leads to code like this https://github.com/seL4/microkit/blob/71e014494367d12f8b12bad9d7d1655778ca2cc2/example/tqma8xqp1gb/ethernet/eth.c#L609
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.