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.
Set the sc field to NULL after manipulating scheduling queues - on smp
we use the sc to obtain the core id. However, also NULL it before
rescheduleRequired or a thread without an SC could end up in the
scheduler.
- use gpt, so we can have overflow and compare interrupts at the same
time (epit only allows compare)
- set the gpt to use the ipg_highfreq timer, as the standard ipg is too
low and breaks the timer calculations
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.
Set sc to NULL before calling reschedule required and check
ksSchedulerAction.
Due to changes in the scheduler (invert-fastpath and friends) reschedule
required would put a thread without an SC into the scheduler, which is
fail.
Prior to this commit we attempted to use reciprocal division to
divide by 1000, which is required on platforms where calculations must
be performed in KHz for precision. This overflowed too quickly.
Use div64 specifically for usToTicks, and move getMaxUsToTicks to the
arch level.
If we modify a scheduling context, and it has a bound TCB, then we need to migrate the TCB
if its affinity should change based on the new affinity of this scheduling context
