-
Notifications
You must be signed in to change notification settings - Fork 63
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add test for AArch64 cache instructions #97
base: master
Are you sure you want to change the base?
Add test for AArch64 cache instructions #97
Conversation
This patch adds a test to ensure that the instructions for cache maintenance from user-space succeed (when the kernel is configured to allow it) Signed-off-by: Ivan-Velickovic <[email protected]>
|
||
/* Now that we have a page of memory in our virtual address space, we can | ||
* test the cache instructions in its virtual address. */ | ||
asm volatile("dc cvau, %0" :: "r"(vaddr)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not super familiar with the sel4test infrastructure, is this the correct way to do this or should I be creating helper threads that execute the instructions and then calling wait_for_helper
? If these instructions fail will it crash the whole sel4test run or will just this test fail?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using a helper thread would be better IMO as it would allow you to catch the fault in the case where the user mode instructions were not enabled. The way it is currently the test thread would fault and you can't tell whether the failure was due to the code-under-test or the test itself. An inverse of the test would be to check that the instructions trigger an seL4_UserException fault if executed when the config option is not enabled.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay cool I'll do it with a helper thread then. Not sure if you saw my comment in the PR description but is there much point in adding the inverse test since it will never be triggered by CI?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You could write the test in a way that it unconditionally runs and just checks that the thread result matches the configuration. You could validate that the test passes for both configurations, and CI will test what ever configurations it tests, but because there's only one test implemented it's less likely to go stale for the other configuration but people can still run sel4test on their specific configuration even if the CI doesn't test it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure thing, I'll add that then.
This patch adds a simple test to ensure that the instructions for cache maintenance from user-space succeed (when the kernel is configured to allow it).
It does not test that the cache operations produce the right side affects, just that they don't cause a fault/exception.
I did not add a test to check that a fault does occur if
CONFIG_AARCH64_USER_CACHE_ENABLE
is not enabled, since sel4test is only run with that config operation enabled.