Skip to content
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

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

Ivan-Velickovic
Copy link
Contributor

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.

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));
Copy link
Contributor Author

@Ivan-Velickovic Ivan-Velickovic Jul 24, 2023

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?

Copy link
Member

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.

Copy link
Contributor Author

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?

Copy link
Member

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.

Copy link
Contributor Author

@Ivan-Velickovic Ivan-Velickovic Jul 24, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants