In RTDS, removing the last eligible pCPU can kill repl_timer.
When a pCPU is later re-added, rt_switch_sched() reinitializes the
timer object, but pending entries may already exist in replq.

Without re-arming from replq head, replenishment can remain inactive
until some unrelated event programs the timer again. This may stall
budget replenishment for non-extratime units.

Fix this by re-arming repl_timer in rt_switch_sched() immediately after
init_timer() when replq is non-empty, using the earliest pending
deadline.

This keeps behavior unchanged when replq is empty.

Add a lightweight regression script,
test_rtds_repl_timer_rearm.sh, to verify source-level guards and model
the expected re-arm decision logic.
Signed-off-by: Oleksii Moisieiev <oleksii_moisieiev@epam.com>
---

 xen/common/sched/rt.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/xen/common/sched/rt.c b/xen/common/sched/rt.c
index 7b1f64a779..59021e1110 100644
--- a/xen/common/sched/rt.c
+++ b/xen/common/sched/rt.c
@@ -741,8 +741,17 @@ rt_switch_sched(struct scheduler *new_ops, unsigned int cpu,
     if ( prv->repl_timer.status == TIMER_STATUS_invalid ||
          prv->repl_timer.status == TIMER_STATUS_killed )
     {
+        struct list_head *replq = rt_replq(new_ops);
+
         init_timer(&prv->repl_timer, repl_timer_handler, (void *)new_ops, cpu);
         dprintk(XENLOG_DEBUG, "RTDS: timer initialized on cpu %u\n", cpu);
+
+        /*
+         * When re-adding CPUs after all RTDS CPUs were removed, replq may
+         * already contain pending replenishment events. Re-arm immediately.
+         */
+        if ( !list_empty(replq) )
+            set_timer(&prv->repl_timer, replq_elem(replq->next)->cur_deadline);
     }
 
     sched_idle_unit(cpu)->priv = vdata;
-- 
2.43.0

base-commit: a7bf8ff218ca05eb3674fdfd2817f6cff471e96a

On 01.04.2026 16:28, Oleksii Moisieiev wrote:
> In RTDS, removing the last eligible pCPU can kill repl_timer.
> When a pCPU is later re-added, rt_switch_sched() reinitializes the
> timer object, but pending entries may already exist in replq.
> 
> Without re-arming from replq head, replenishment can remain inactive
> until some unrelated event programs the timer again. This may stall
> budget replenishment for non-extratime units.
> 
> Fix this by re-arming repl_timer in rt_switch_sched() immediately after
> init_timer() when replq is non-empty, using the earliest pending
> deadline.
> 
> This keeps behavior unchanged when replq is empty.
> 
> Add a lightweight regression script,
> test_rtds_repl_timer_rearm.sh, to verify source-level guards and model
> the expected re-arm decision logic.
> Signed-off-by: Oleksii Moisieiev <oleksii_moisieiev@epam.com>

What is this last (improperly separated from the S-o-b) paragraph about?
No ...

> ---
> 
>  xen/common/sched/rt.c | 9 +++++++++
>  1 file changed, 9 insertions(+)

... new script is being introduced.

Jan

On 01/04/2026 17:31, Jan Beulich wrote:
> On 01.04.2026 16:28, Oleksii Moisieiev wrote:
>> In RTDS, removing the last eligible pCPU can kill repl_timer.
>> When a pCPU is later re-added, rt_switch_sched() reinitializes the
>> timer object, but pending entries may already exist in replq.
>>
>> Without re-arming from replq head, replenishment can remain inactive
>> until some unrelated event programs the timer again. This may stall
>> budget replenishment for non-extratime units.
>>
>> Fix this by re-arming repl_timer in rt_switch_sched() immediately after
>> init_timer() when replq is non-empty, using the earliest pending
>> deadline.
>>
>> This keeps behavior unchanged when replq is empty.
>>
>> Add a lightweight regression script,
>> test_rtds_repl_timer_rearm.sh, to verify source-level guards and model
>> the expected re-arm decision logic.
>> Signed-off-by: Oleksii Moisieiev <oleksii_moisieiev@epam.com>
> What is this last (improperly separated from the S-o-b) paragraph about?
> No ...
>
Sry for that. this leftover from squashing... Will remove. Made a unit 
tests to check the behavior.
>> ---
>>
>>   xen/common/sched/rt.c | 9 +++++++++
>>   1 file changed, 9 insertions(+)
> ... new script is being introduced.
>
> Jan