ARINC653 specificaion requires partition scheduling to be deterministic
and periodic over time.

However, the use of current timestamp (now) as the baseline to calculate
next_major_frame and next_switch_time introduces a delay in the start of
major frame at every period, which breaks determinism and periodicity in
partition scheduling.

For example, we observe 3.5 msec of accumulated delay at the 21st major
frame with the following configuration.

Target : qemuarm64
xen version : 4.19 (43aeacff86, x86/IRQ: constrain creator-domain-ID assertion)
dom1 : 10 msec runtime
dom2 : 10 msec runtime

$ a653_sched -p Pool-arinc dom1:10 dom2:10

0.014553536 ---x d?v? runstate_change d1v0 runnable->running //1st major
frame
0.034629712 ---x d?v? runstate_change d1v0 runnable->running //2nd major
frame
<snip>
0.397747008 |||x d?v? runstate_change d1v0 runnable->running //20th
major frame
0.418066096 -||x d?v? runstate_change d1v0 runnable->running //21st
major frame

This is due to an inherent delta between the time value the scheduler timer
is programmed to be fired with and the time value the schedule function
is executed.

Another observation that breaks the deterministic behavior of partition
scheduling is a delayed execution of schedule(); It was called 14 msec
later than programmed.

1.530603952 ---x d?v? runstate_change d1v0 runnable->running
1.564956784 --|x d?v? runstate_change d1v0 runnable->running

Enforce the periodic behavior of partition scheduling by using the value
next_major_frame as the base to calculate the start of major frame and
the next domain switch time. In addition, push next_switch_time until
it's behind the current time to ensure positive runtime for the newly
selected domain to run.

Signed-off-by: Anderson Choi <anderson.choi@boeing.com>
---
Cc: Nathan Studer <nathan.studer@dornerworks.com>
Cc: Stewart Hildebrand <stewart@stew.dk>
Cc: Dario Faggioli <dfaggioli@suse.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: George Dunlap <gwd@xenproject.org>

 xen/common/sched/arinc653.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/xen/common/sched/arinc653.c b/xen/common/sched/arinc653.c
index 930361fa5c..61e94dcc96 100644
--- a/xen/common/sched/arinc653.c
+++ b/xen/common/sched/arinc653.c
@@ -534,8 +534,12 @@ a653sched_do_schedule(
          * the first time this function is called, this will be true */
         /* start with the first domain in the schedule */
         sched_priv->sched_index = 0;
-        sched_priv->next_major_frame = now + sched_priv->major_frame;
-        sched_priv->next_switch_time = now + sched_priv->schedule[0].runtime;
+
+        /* Enforce periodic start of major frame and domain switches */
+        do {
+            sched_priv->next_switch_time = sched_priv->next_major_frame + sched_priv->schedule[0].runtime;
+            sched_priv->next_major_frame += sched_priv->major_frame;
+        } while (now >= sched_priv->next_switch_time);
     }
     else
     {
-- 
2.43.0

On Wed, 2025-07-09 at 09:08 +0900, Anderson Choi wrote:
> ARINC653 specificaion requires partition scheduling to be
> deterministic
> and periodic over time.
> 
> However, the use of current timestamp (now) as the baseline to
> calculate
> next_major_frame and next_switch_time introduces a delay in the start
> of
> major frame at every period, which breaks determinism and periodicity
> in
> partition scheduling.
>
> [...]
> 
> Enforce the periodic behavior of partition scheduling by using the
> value
> next_major_frame as the base to calculate the start of major frame
> and
> the next domain switch time. In addition, push next_switch_time until
> it's behind the current time to ensure positive runtime for the newly
> selected domain to run.
> 
This looks fine and correct to me, and it does indeed make perfect
sense according to my knowledge of periodic real-time scheduling.

I think the patch can have my:
Acked-by: Dario Faggioli <dfaggioli@suse.com>

With the only caveat that I don't have any specific knowledge or
experience with the details of the ARINC653 algorithms, and hence I
cannot tell for sure whether or not the new behavior is also more
adherent to the standard (although, I suspect it does) or not.

If we want/need this kind of guarantee too, I hope that Stewart and/or
Nathan can help...

Regards,
-- 
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
-------------------------------------------------------------------
<<This happens because _I_ choose it to happen!>> (Raistlin Majere)