PR #36996 disabled running mem_protect/stack_random test on qemu_riscv32
platform because of this test consistently failing on said platform.
This test starts new threads in equal time intervals, and because of
that we get repeating values after performing the modulus operation when
calculating the stack pointer address.
This can be solved by changing the value of the _RAND32_INC constant
that is used to increase the value returned by the timer-based PRNG.
This commit decreases the value of the mentioned constant from
1000000013U to 1000000003U.
Fixes#37006.
Signed-off-by: Filip Kokosinski <fkokosinski@antmicro.com>
Cleanup and preparation commit for linker script generator.
Zephyr linker scripts provides start and end symbols for each larger
areas in the linker script.
The symbols _image_rom_start and _image_rom_end corresponds to the group
ROMABLE_REGION defined in the ld linker scripts.
The symbols _image_rodata_start and _image_rodata_end is not placed as
independent group but covers common-rom.ld, thread-local-storage.ld,
kobject-rom.ld and snippets-rodata.ld.
This commit align those names and prepares for generation of groups in
linker scripts.
The symbols describing the ROMABLE_REGION will be renamed to:
_image_rom_start -> __rom_region_start
_image_rom_end -> __rom_region_end
The rodata will also use the group symbol notation as:
_image_rodata_start -> __rodata_region_start
_image_rodata_end -> __rodata_region_end
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
This enables qemu_x86_tiny to be used for more general demand
paging testing where non-pinned code and data is not available
in physical memory at boot. This adds a custom linker script to
qemu_x86_tiny for pinning code and data. In the process, a new
kconfig CONFIG_BOARD_QEMU_X86_TINY has to be introduced to
distinguish from other qemu_x86* boards. This linker script
is based on the generic x86-32 one in
include/arch/x86/ia32/linker.ld, with additions to
put symbols into boot and pinned sections.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
This pins the test_page in memory for tests about memory
mapping. This is simply to make sure the whole array
is in physical memory for mapping or else the mapping
function would fail due to having nothing to map.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
If pinned section is enabled, _k_neg_eagain should be in pinned
rodata section. So add the check if pinned section is enabled.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
This puts the fatal error handler into pinned sections so
it can be used to handle fatal errors without causing
page faults.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Move to CMake 3.20.0.
At the Toolchain WG it was decided to move to CMake 3.20.0.
The main reason for increasing CMake version is better toolchain
support.
Better toolchain support is added in the following CMake versions:
- armclang, CMake 3.15
- Intel oneAPI, CMake 3.20
- IAR, CMake 3.15 and 3.20
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
The default address for FAULTY_ADDRESS is valid on the qemu_cortex_r5
board, so use a value that is not mapped for that board.
Signed-off-by: Bradley Bolen <bbolen@lexmark.com>
In test_kobject_release_null(), dummy is not initialized
before being fed to k_object_release(). So set it.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Test fails consistently in CI but local builds succeed. Puzzling. In
order to keep main green, disabling this test only for qemu_riscv32
until a solution is found.
```
% west build -p always -b qemu_riscv32 -t run \
tests/kernel/mem_protect/stack_random
...
*** Booting Zephyr OS build zephyr-v2.6.0-1039-g523764b3fd75 ***
Running test suite stack_pointer_randomness
===================================================================
START - test_stack_pt_randomization
Test Stack pointer randomization
stack pointer changed 13 times out of 64 tests
PASS - test_stack_pt_randomization in 0.5 seconds
===================================================================
Test suite stack_pointer_randomness succeeded
===================================================================
PROJECT EXECUTION SUCCESSFUL
```
```
*** Booting Zephyr OS build zephyr-v2.6.0-1063-g0106d8f2a391 ***
Running test suite stack_pointer_randomness
===================================================================
START - test_stack_pt_randomization
Test Stack pointer randomization
stack pointer changed 0 times out of 64 tests
Assertion failed at WEST_TOPDIR/zephyr/tests/kernel/mem_protect/\
stack_random/src/main.c:68: test_stack_pt_randomization: \
(sp_changed equal to 0)
Stack pointer is not randomized
FAIL - test_stack_pt_randomization in 0.6 seconds
===================================================================
Test suite stack_pointer_randomness failed.
===================================================================
PROJECT EXECUTION FAILED
```
Signed-off-by: Christopher Friedt <chrisfriedt@gmail.com>
We have some static variables var, zeroed_var and bss_var
in mem_partition.c and we only assert the value of them in
the same file, so the compiler may pre-calculate it in compile
stage, it's fine usually.
But for variable zeroed_var (= 20420), we force to put it in bss
section in link stage, the value will change in bss clean stage, so
we will get a wrong result.
Let's add volatile for these variables to disable pre-calculation.
Signed-off-by: Watson Zeng <zhiwei@synopsys.com>
These functions are those that need be implemented by backing
store outside kernel. Promote them from z_* so these can be
included in documentation.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
These functions and data structures are those that need
to be implemented by eviction algorithm and application
outside kernel. Promote them from z_* so these can be
included in documentation.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
The variable cnt is assigned twice in a row, so remove
the first one.
Coverity-CID: 235962
Fixes#35161
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Remove this intrusive tracing feature in favor of the new object tracing
using the main tracing feature in zephyr. See #33603 for the new tracing
coverage for all objects.
This will allow for support in more tools and less reliance on GDB for
tracing objects.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
This adds a test for z_phys_unmap() to make sure that memory
can be unmapped and is no longer accessible.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
This waits a bit for NRU eviction algorithm (which is the default)
to work its magic to clear the access bit of physical frames.
This increases the number of clean pages which can be evicted,
to make sure the number of clean pages evicted is not zero, which
would cause an assertion.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
The test itself is highly sensitive to the size of the kernel
image. When the kernel gets larger, the number of pages used by
the backing store needs to shrink. So here this is.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
This test fails on qemu_arc_{em|hs} consistently,
due to bug in quem_arc, details:
https://github.com/foss-for-synopsys-dwc-arc-processors/qemu/issues/14.
To get clean results we need to disable this test until the
bug is fixed and fix gets propagated to new Zephyr-SDK.
Signed-off-by: Watson Zeng <zhiwei@synopsys.com>
This adds FPU sharing support with a lazy context switching algorithm.
Every thread is allowed to use FPU/SIMD registers. In fact, the compiler
may insert FPU reg accesses in anycontext to optimize even non-FP code
unless the -mgeneral-regs-only compiler flag is used, but Zephyr
currently doesn't support such a build.
It is therefore possible to do FP access in IRS as well with this patch
although IRQs are then disabled to prevent nested IRQs in such cases.
Because the thread object grows in size, some tests have to be adjusted.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
Add a test case to validate when adding a new partition into a memory
domain with over its maximum specified limit number, an assertion
failure happens.
Signed-off-by: Maksim Masalski <maksim.masalski@intel.com>
Signed-off-by: Enjia Mai <enjiax.mai@intel.com>
Found out that important requirements are not tested by current
kernel objects tests. Decided to fix that situation
New added tests:
1. test_kobj_assign_perms_on_alloc_obj()
Create kernel object semaphore, dynamically allocate it from the
calling thread's resource pool.
Check that object's address is in bounds of that memory pool.
Then check the requestor thread will implicitly be assigned
permission on the allocated object by using
semaphore API k_sem_init()
2. test_no_ref_dyn_kobj_release_mem()
Dynamically allocated kernel objects whose access is controlled by
the permission system will use object permission as a reference count
If no threads have access to an object, the object's memory released.
Signed-off-by: Maksim Masalski <maksim.masalski@intel.com>
This adds bits to support using timing functions for displaying
paging histograms. Currently on qemu_x86_tiny is supported.
Also shorten the test names.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
This adds more bits to gather statistics on demand paging,
e.g. clean vs dirty pages evicted, # page faults with
IRQ locked/unlocked, etc.
Also extends this to gather per-thread demand paging
statistics.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
This functions is being called across the tree, no reason why it should
not be a public API.
The current usage violates a few MISRA rules.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Split ARM and ARM64 architectures.
Details:
- CONFIG_ARM64 is decoupled from CONFIG_ARM (not a subset anymore)
- Arch and include AArch64 files are in a dedicated directory
(arch/arm64 and include/arch/arm64)
- AArch64 boards and SoC are moved to soc/arm64 and boards/arm64
- AArch64-specific DTS files are moved to dts/arm64
- The A72 support for the bcm_vk/viper board is moved in the
boards/bcm_vk/viper directory
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
We are setting CONFIG_GEN_PRIV_STACKS when AArch64 actually uses a
statically allocated privileged stack.
This error was not captured by the tests because we only verify whether
a read/write to a privileged stack is failing, but it can fail for a lot
of reasons including when the pointer to the privileged stack is not
initialized at all, like in this case.
With this patch we deselect CONFIG_GEN_PRIV_STACKS and we fix the
mem_protect/userspace test to correctly probe the privileged stack.
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
Add some error test cases for userspace of memory protection module.
This increase the code coverage of testing.
Signed-off-by: Enjia Mai <enjiax.mai@intel.com>
This reverts commit 9de70a78fe.
The tests have been updated so there is no need to skip tests
when the kernel is linked in virtual address space.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Replace *_thread_resource_pool_assign() in the reference with the new
k_thread_heap_assign() since both k_thread_resource_pool_assign() and
z_thread_resource_pool_assign() has been removed prio to v2.5 (by the
commit c770cab1a3 and 3c2c1d85b0 respectively) along with the
k_mem_pool API removal.
For the resource pool inheritance test, the variables with "res_pool"
string has been replaced by "heap_mem" to align with the documentation
fix. No functionality has been changed.
Signed-off-by: Yasushi SHOJI <yashi@spacecubics.com>
This is the same problem as seen for #32053. Refer to that for the
details and propose a similar fix.
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
When the kernel links in virtual address space, the data
structures needed for the z_phys_map() no longer point to physical
addresses (which are required for z_phys_map() to work). So skips
these tests if CONFIG_KERNEL_LINK_IN_VIRT=y.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
When the kernel is TICKLESS, timeouts are set as needed, and drivers
all have some minimum amount of time before which they can reliably
schedule an interrupt. When this happens, drivers will kick the
requested interrupt out by one tick. This means that it's not
reliably possible to get a timeout set for "one tick in the
future"[1].
And attempting to do that is dangerous anyway. If the driver will
delay a one-tick interrupt, then code that repeatedly tries to
schedule an imminent interrupt may end up in a state where it is
constantly pushing the interrupt out into the future, and timer
interrupts stop arriving! The timeout layer actually has protection
against this case.
Finally getting to the point: in recent changes, the timeslice layer
lost its integration with the "imminent" test in the timeout code, so
it's now able to run into this situation: very rapidly context
switching code (or rapidly arriving interrupts) will have the effect
of infinitely[2] delaying timeouts and stalling the whole timeout
subsystem.
Don't try to be fancy. Just clamp timeslice duration such that a
slice is 2 ticks at minimum and we'll never hit the problem. Adjust
the two tests that were explicitly requesting very short slice rates.
[1] Of course, the tradeoff is that the tick rate can be 100x higher
or more, so on balance tickless is a huge win.
[2] Actually it only lasts until a 31 bit signed rollover in the HPET
cycle count in practice.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The inheritance test first creates a parent thread, and then
creates a child thread inside this parent thread. At the same
time inside the main thread, a resource pool is assigned to
the parent thread. However, when under SMP, it is possible
that the pool assignment is done between both parent/child
threads are getting pointers to the pool, due to multiple
threads are running. So when doing pool pointer comparison,
there is a mismatch between those pointers (like parent has
a null pool pointer while child is pointing to the actual
pool), and thus failing the test. So fix this by delaying
the parent from running under after pool assignment is done.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
When coverage is enabled on x86_64, GCC uses relative addressing
to increment the gcov counters. The generated code of the test
function assumes execution is in the same location where
the linker places the test function. This does not work with
the execution test as it copies the function into another part
of memory and tries to execute from there. When the copied
function starts to run, the instruction pointer is at the newly
copied function. So any relative addressing with regard to
the instruction pointer now is invalid. Instead of
<generated code RIP + offset> for gcov counter as it should be,
now the copied code is trying to access the counter at
<copied code RIP + offset>, which points to incorrect
memory location (and possibly invalid/non-mapped memory).
To fix this, we need to tell GCC not to use relative addressing.
This can be accomplished by telling GCC to use the large memory
model. This is only used for this test as this option increases
code size quite a bit, and should not be used in general.
Fixes#30434
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
This puts the transplanted_function into its own section so that
z_phys_map() can correctly map the whole range of memory used
by the function, in case someone decides to expand the function
to be bigger than a MMU page.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
The test_mem_domain_migration test creates a new thread with
different priority based on whether SMP is enabled. This causes
an issue where SMP=y and MP_NUM_CPUS=1 where the spin_entry()
would spin forever (with k_busy_wait()) and not yielding since
it has cooperative priority. Fix this by using MP_NUM_CPUS to
figure out which priority to use, as it is valid configuration
to have SMP=y and MP_NUM_CPUS=1.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Some arches like x86 need all memory mapped so that they can
fetch information placed arbitrarily by firmware, like ACPI
tables.
Ensure that if this is the case, the kernel won't accidentally
clobber it by thinking the relevant virtual memory is unused.
Otherwise this has no effect on page frame management.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Filip Kokosinski