tests: z_test_1cpu_start() makes only CPU0 active #70579
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When z_test_1cpu_start() is called to ensure that only a single CPU on an SMP system is available for use in a test, this commit will ensure that that CPU is the primary CPU--CPU0. This is done because some timer drivers only have the timer interrupt processed by one CPU.
A bit of a song and dance is performed to achieve this without enabling the CPU mask/affinity pinning API. If the cpuhold thread is found to be executing on CPU0, then a new copy of cpuhold thread is created. Once the new copy is executing (incidentally guaranteed to be on another CPU) then it informs the original copy and busy waits until it the original copy is switched out of CPU0. At this point, we can create the next cpuhold thread to occupy another CPU if needed.
During this song and dance, it is critical that the 'copy' not pend. If it pends, we can not guarantee which CPU it will execute on when it unpends. As the cpuhold threads have the highest priority, nothing is going to cause them to execute on another CPU for as long as they do not pend.
Fixes #70494