[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] sched/rtds: refill cur_budget when extratime is toggled on a depleted vCPU
- To: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- From: Oleksii Moisieiev <oleksii_moisieiev@xxxxxxxx>
- Date: Wed, 10 Jun 2026 09:50:26 +0300
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=pP87thhXIgbwA+WweNhF1apOKmvKrNauHXGewln+GCg=; b=wuhtxNA5gVfNKiBOEWvytbchl6SlVa1U7XqGFLUAULUftekfCUyvY5Iz+2pqT6O8idjlhDY6pLGB8lSJVXGUiw1nt2zH4U8k6j197SKV6fj8g1BwuOdMYXfhdQm1w/KhiWaDqwPB7bDtnqrRDZghBW6zlZDl7FK0ruE8u6boQm8fmb1haZCxjE64BoaPNFwvZGOEAB8ZJUG1ZLx0oCsXr6zFjm/Kd/IcbpXx0O+vDMkIMejT6kHqAXhdi8zSfjJ+H2xrapQBCjvFqpoy7dk14dXK3xD+OcWgzYB9P3iZ4E2ky3w4Tc5syRt7HV50uTfyw8P92XNdJDFBslhgulZU8w==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=lcWbvYhe6v9UDDMRhvwpHFJ5rknKULuPq6chlVxvxXn3n1e9BOx7ULBosusSbfiufTJTOAMkgAdL/ixyaTLGFYw3pTi76tiCchfL3eBhGE56427vkZrk4NDVV1gWrqGkTAWvfLGEK6f3cy1RQj7ev8gEn0d5sUxjEaDQx6f/6PDFmBb/foegBStvginN3N+1a8paKbbJq/ngRjPr8xlhwlF8IOZhqLj/CxKVvfQUAPztB4CO0UDTiCba4qEkpD7bTkJEROxxGPobCXEMkwd2FYnRB4LNPm18D8+Atipkl9YDmlLLrwcB9dUFJCO3z6FR77UuIJvtRuOPBUArJMD0Zg==
- Authentication-results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com;
- Cc: Dario Faggioli <dfaggioli@xxxxxxxx>, George Dunlap <gwd@xxxxxxxxxxxxxx>, Juergen Gross <jgross@xxxxxxxx>, Meng Xu <mengxu@xxxxxxxxxxxxx>
- Delivery-date: Wed, 10 Jun 2026 06:50:50 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
Gentle Ping.
I've already got R-b from Juergen. Maybe someone else will have time to
review?
Oleksii
On 20/05/2026 16:57, Oleksii Moisieiev wrote:
XEN_DOMCTL_SCHEDOP_putvcpuinfo can flip the RTDS_extratime bit on a vCPU
that is currently depleted (cur_budget == 0, possibly sitting on the
depleted queue). rt_dom_cntl() touches only svc->flags; cur_budget is
left unchanged. As a result the next code path that calls runq_insert()
on this vCPU - rt_unit_wake() after a domain_unpause(),
rt_context_saved() following a delayed runq add, or repl_timer_handler()
after a replenishment - places the vCPU on the run queue, because
has_extratime(svc) is now true and runq_insert() admits extratime units
regardless of cur_budget:
/* add svc to runq if svc still has budget or its extratime is set */
if ( svc->cur_budget > 0 ||
has_extratime(svc) )
deadline_runq_insert(svc, &svc->q_elem, runq);
else
list_add(&svc->q_elem, &prv->depletedq);
The very next rt_schedule() iterates the run queue from runq_pick()
and trips the ASSERT(iter_svc->cur_budget > 0) at the bottom of the
loop, panicking the host. Observed trace:
Assertion 'iter_svc->cur_budget > 0' failed at common/sched/rt.c:1035
----[ Xen-4.22-unstable arm64 debug=y ubsan=y Not tainted ]----
[<...>] rt.c#rt_schedule+0x1558/0x33e0 (PC)
[<...>] core.c#do_schedule+0x2e4/0x15b4
[<...>] core.c#schedule+0xb14/0xe50
[<...>] softirq.c#__do_softirq+0x20c/0x3d4
[<...>] do_softirq+0x14/0x1c
[<...>] domain.c#idle_loop+0x194/0x558
Minimal reproducer: pin a single-vCPU domU to a pCPU, program RTDS with
extratime off and a low utilisation (e.g. budget = 10ms / period = 100ms)
so the vCPU spends most of its time in the depleted queue, pause the
domain, issue a putvcpuinfo that sets XEN_DOMCTL_SCHEDRT_extra, then
unpause. As soon as the schedule softirq fires on the pCPU, the BUG
hits. The same sequence is reachable without an explicit pause: any
window in which rt_dom_cntl() runs between burn_budget()'s budget
exhaustion and rt_context_saved()'s runq_insert() also closes onto the
same broken state, because the per-scheduler lock is dropped between
those two points.
The semantics for "extratime gets exhausted budget refilled" already
live in burn_budget():
if ( has_extratime(svc) )
{
svc->priority_level++;
svc->cur_budget = svc->budget;
}
Apply the same priority-demotion-and-refill in rt_dom_cntl() when the
flag transitions from off to on while the vCPU is depleted, clear
RTDS_depleted to match, and - if the vCPU is currently on the depleted
queue - move it to the run queue using the same q_remove() +
runq_insert() pattern already used by repl_timer_handler(). The vCPU
remains on the replenishment queue throughout, so its normal
replenishment cadence is preserved.
The complementary transition (on -> off) is already safe: clearing the
flag only narrows the runq_insert() admission condition, so subsequent
depleted insertions correctly route to the depleted queue.
No other call sites need changes: with cur_budget restored before the
flag is observable to runq_insert(), runq_pick()'s long-standing
invariant (every run-queue entry has cur_budget > 0) is preserved.
Signed-off-by: Oleksii Moisieiev <oleksii_moisieiev@xxxxxxxx>
---
xen/common/sched/rt.c | 34 ++++++++++++++++++++++++++++++++++
1 file changed, 34 insertions(+)
diff --git a/xen/common/sched/rt.c b/xen/common/sched/rt.c
index b156f61afa..18e39977be 100644
--- a/xen/common/sched/rt.c
+++ b/xen/common/sched/rt.c
@@ -1465,7 +1465,41 @@ rt_dom_cntl(
svc->period = period;
svc->budget = budget;
if ( local_sched.u.rtds.flags & XEN_DOMCTL_SCHEDRT_extra )
+ {
+ /*
+ * Turning extratime on while the vCPU is depleted
+ * (cur_budget <= 0) leaves cur_budget unchanged. The
+ * next runq_insert() on this vCPU - from
+ * rt_unit_wake() after a domain unpause,
+ * rt_context_saved() following a delayed runq add, or
+ * repl_timer_handler() - then places it on the run
+ * queue because has_extratime() is now true, even
+ * though cur_budget is 0. The very next rt_schedule()
+ * iterates the run queue from runq_pick() and trips
+ * the ASSERT(iter_svc->cur_budget > 0).
+ *
+ * Apply the same priority-demotion-and-refill that
+ * burn_budget() would have performed if the flag had
+ * been set when the budget ran out, clear the
+ * depleted state, and - if the vCPU is currently on
+ * the depleted queue - move it to the run queue so
+ * the new extratime allocation is picked up
+ * immediately instead of waiting for the next
+ * replenishment.
+ */
+ if ( !has_extratime(svc) && svc->cur_budget <= 0 )
+ {
+ svc->priority_level++;
+ svc->cur_budget = svc->budget;
+ __clear_bit(__RTDS_depleted, &svc->flags);
+ if ( unit_on_q(svc) )
+ {
+ q_remove(svc);
+ runq_insert(ops, svc);
+ }
+ }
__set_bit(__RTDS_extratime, &svc->flags);
+ }
else
__clear_bit(__RTDS_extratime, &svc->flags);
spin_unlock_irqrestore(&prv->lock, flags);
|