Instead of exporting the generic timer and counter access to userland in
one go, this commit splits it up into two different operations which
require two different build flags to be turned on. This is because the
timers expose a storage channel and allow threads to corrupt the
registers for each other.
Also move the config options to a better location and have them
depend on a more suitable config flag.
- allow the compare register to be set by user level (for both
virtual and physical timer.
- allow the generic timer to be exported to EL1 as well when running
seL4 as a hypervisor
This prevents accidental declaration of properties or configurations
that are for the incorrect architecture selected. This was previously
required as the variables KernelWordSize and KernelArch were defined in
each arch specific cmake.config file. Now that they are defined in
advance it is possible to exclude the other imports.
On aarch64 physBase is the constant that points to the bottom of
physical memory (RAM).
Prior to this change the kernel window was mapped directly to physBase,
which is usually not a 0 paddr. As a consequence the kernel could not
access any memory below physBase.
This change fixes this issue by mapping the start of the kernel window
to 0 in the physical address space.
- add new constant PADDR_LOAD, the location of the kernel image in the
physical address space.
- add new constant PADDR_BASE, the start of the physical address space
(0).
- add new constant KERNEL_ELF_BASE, the location of the kernel image in
kernel virtual memory.
A consequence of this change is that on aarch64, the kernelBase constant
now points to the start of the kernel window in virtual memory, but
*not* to the start of the kernel image as these are now different.
Prior to this commit this check would fail on ARMv8.2 and greater, as
having a bit set after this version does not imply that FPU/SIMD is not
supported.
For ARMv8.2 and above the values of the AdvSIMD/FP bits in
ID_AA64PFR0_EL1 are as follows:
- 0b1111 means FPU/SIMD is not supported.
- 0b0000 means FPU/SIMD is supported except for half-precision floating
point arithmetic.
- 0b0001 means FPU/SIMD is supported including half-precision floating
point arithmetic.
Make sure that when the kernel boots a scheduling control cap is created
and that the initial thread and idle thread are scheduled using correct
systemt time.
mcs requires an additional 2 registers for performing system calls to
pass information regarding the reply capability and the destination of a
nbsend/recv.
Preemption can be triggered due to a revoke operation, which may have
deleted one or both of the current thread and current scheduling
context. Don't manipulate the current thread if it is no longer valid
and just charge the SC iff it is valid and the thread is not.
This was discovered during verification.
ChargeBudget can be called after a preemption, but the preemption may
have deleted the scheduling context. Do not charge scheduling contexts
that have been deleted (check scRefillMax).
Preemption can be via the timer interrupt. In this case we need to
update the timestamp so we can reprogram the timer for the next timeout
and guarantee it is in the future, otherwise we will end up setting a
timeout in the past.
Prior to this change calling yieldTo on an sc with a thread that was not
in the scheduler and had an insufficient/unready head replenishment
would be added incorrectly to the scheduler.
If the thread isn't in the scheduler, use schedcontext_resume to ensure
that it is in the release queue if it has an insufficient/unready head
replenishment, and thus prevent that thread from being added to the
scheduler.
If the scheduling context is changed on the currently running thread
this causes issues if the operation triggers a preemption. This change
makes the proofs easier, and also makes sense for the api, as users
wishing to suspend the current thread should just use Suspend.
A fault message is an IPC. Threads which have faulted can be inactive,
blocked on send, or blocked on reply. Always clear tcbFault when
cancelling IPC to make sure restarted threads are not in a fault state.
Some invocations contain two phases, and certain operations cannot be
allowed to run in the first phase as it could effect the currently
running thread and result in an invalid system state for the second
phase. This change filters those invocations, preventing them from being
used in the first phase of a two-phase, blocking system call.
If we're in a scenario where do_call or fault is set, but there is no
reply, the calling/faulting thread needs to be set to inactive to
prevent it reentering the scheduler in a bad state. If the reply is set,
then the calling/faulting thread is set to blocked on reply correctly.
If a thread's fault endpoint has been deleted, such that cancelAllIPC is
called on that endpoint, set the thread state to inactive. This prevents
threads with faults from entering the run queue and makes the
behaviour consistent with threads faulting without a fault handler set.
This came up as verification now need the invariant that threads in the
runqueue have no faulted, an invariant not required before MCS.
Previously the behaviour was not broken, as threads would just refault
and be made inactive at that point.
Schedcontext_bind is currently called in ThreadControl, which
manipulates capabilities which in turn can result in KsSchedulerAction
being deleted. This means that we cannot use possibleSwitchTo in this
function.
This is a stop-gap fix for verification, the long term fix is to split
setting scheduling parameters from ThreadControl, then we can return to
a direct switch, and also do a direct switch for other thread/scheduler
settings like priorities.
When setting a thread priority, we need to check if it is in the
scheduler before putting it back in the scheduler, otherwise we do not
know enough about the scheduling context to know that the thread is
active.
Rather than preserving the chain break it completely. This changes the
semantics such that if a reply is removed in the middle of a call
chain, a donated scheduling context cannot return to the original
caller.
When yieldingTo a same prio thread, the same prio thread should run
first, not the current thread. Due to changes to possibleSwitchTo in
master scheduler this code became outdated and the current thread would
be rescheduled immediately.
The desired behaviour is that the thread being yieldedTo should be at
the head of the scheduler queue for its priority, and the current thread
should be just after it.
We use the chargeBudget logic in the kernel on seL4_Yield to free up
the budget available in the head refill, however this
updates scConsumed. Given this is a simulated charge (the thread is
yielding the budget, not actually using it), this is incorrect.
Installing the endpoint caps before the CSpace/VSpace roots is easier
for verification, because deleting endpoint caps is always well-behaved,
but CNode cap deletion can be complex.
This handles the specific case where a thread has donated its SC
over a Call but then is bound to another SC before the reply is
executed. In this edge-case, the donated SC remains with the callee.
Before this change, we set the replyObject in the thread state on recv
with no back pointer such that stray pointers would be left in the
thread state when a reply object was completed.
The new semantics are clearer and fix this problem by doing the
following:
- tcb->tcbReply is removed and the thread state field is always used,
this was unneccessary duplication previously
- the thread state value is set to the reply object only when the thread
is in BlockedOnReply or BlockedOnRecv
- the reply contains a back pointer, replyTCB, which points to that
thread
- if a thread has its reply removed, it must be set to
ThreadState_Inactive.
- deletion is easy in the blockedOnRecv case, we just unlink the reply
and the tcb.
- deletion is complicated for blockedOnReply. If we are deleing a tcb,
we remove the actual reply object and the call chain is broken. If we
are deleting a reply, we maintain the call chain by moving the tcb to
the next reply.
- we refactor the reply object interface to solve the above.
* reply_clear: removes the reply from any connections (tcb, sc)
* reply_unlink: just unlinks the tcb and reply, and sets the thread
state to inactive
* reply_remove: removes the reply from the call chain
* reply_remove_tcb: removes the exact reply that a tcb is bound to,
as we are removing that tcb. Breaks the call chain.
- seL4_TCB_Configure no longer takes a fault endpoint.
- seL4_TCB_SetSpace takes a cap in the callers cspace for the
fault endpoint, not the target tcbs.
- seL4_TCB_SetSchedParams now also takes a fault endpoint as above.
This change installs the fault endpoint cap into the tcb cnode
first validating it.
This means either of the functions that set it will now return an error
if the cap is not either a null cap or an endpoint with send and
grant rights.
Significantly, the cap passed to the function should be in the callers
cspace, not the target tcbs.
