überXMHF (rpi3-armv8_32): Add multi-mode capabilities to mixed-trust scheduler üapp

This task will add multi-mode (varying timing) capabilities to the mixed-trust scheduler üapp (see: überXMHF (rpi3-armv8_32): Add mixed-trust scheduler üapp and MAVLINK serial-heartbeat protocol üapp)

Linked (test) branches:

Branch feature-uapp-hypmtscheduler-multimode within https://github.com/amitvasudevan/uberxmhf.git

Hi @dionisiodeniz

The following are the list of sub-tasks that will comprise the multi-mode implementation within uapps/uapp-hypmtscheduler per my current understanding:

  1. change uapp_hypmtscheduler_handlehcall_guestjobstart within uapp-hypmtscheduler.c to return the current mode for the given hyptask handle

  2. update struct sched_timer within include/hypmtscheduler.h to move time period fields and hyptask callback function pointer into an array to give it a multi-mode organization. Add a new field current_mode which indexes into this array; current_mode=0 is the default behavior of the current single-mode timer.

  3. Propagate the above organization into the existing logic of the mixed-trust scheduler, so that it works as before with current_mode=0

  4. Change uapp_hypmtscheduler_handlehcall_createhyptask to always use mode index 0 --> default single-mode behavior

  5. Add new hypercall uapp_hypmtscheduler_handlehcall_createhyptask_addmode which takes a hyptask_handle, first_period, regular_period, hyptask_id, flag and mode_id parameter and adds it to the mode list of the timer referenced by hyptask_handle

    • flag=beginning --> call mode_switch (see below) in the beginning
    • flag=end --> call mode_switch (see below) in the end
  6. modify uapp_sched_process_timers to invoke a mode_switch function which returns the mode to switch to (this can currently be a function that basically implements a state machine type of mode switch). If the new mode is different from the current mode then go ahead and use the new mode in the
    uapp_sched_timer_redeclare() call.

Let me know your thoughts…Thanks!

Have finished sub-tasks (2), (3) and (4) above and pushed my changes into the branch pinned within the OP.

Change this to a new hypercall uapp_hypmtscheduler_handlehcall_createhyptask_addmode which takes a hyptask_handle, first_period, regular_period, hyptask_id, flag and mode_id parameter and adds it to the mode list of the timer references by hyptask_handle

flag=beginning --> call mode_switch in the beginning
flag=end --> call mode_switch in the end

Just knocked out sub-task (1). Added the following supporting function within uxmhf-rpi3/rgapps/linux/ugapp-hypmtscheduler-zsrmv/hypmtscheduler_kmodlib.c:

bool hypmtscheduler_guestjobstart_returnmode(u32 hyptask_handle, u32 *mode);

This returns true/false to signify if the operation succeeded. If the return value is true then mode contains the current mode of the hyptask_handle

Finished subtask (5). Added the following supporting function within uxmhf-rpi3/rgapps/linux/ugapp-hypmtscheduler-zsrmv/hypmtscheduler_kmodlib.c to add a mode to a created hyptask:

bool hypmtscheduler_hyptaskaddmode(u32 hyptask_handle, u32 first_period, u32 regular_period,
u32 hyptask_id, u32 hyptask_modeswitch_flag, u32 hyptask_modeid) ;

This returns true if the operation succeeded. Here:

  • hyptask_id is an integer < HYPMTSCHEDULER_MAX_HYPTASKID
  • hyptask_modeid is an integer < MAX_TIMER_MODES

The aforementioned constants are defined within uxmhf-rpi3/include/hypmtscheduler.h

Finished subtask (6) and successfully tested with uxmhf-rpi3/rgapps/linux/ugapp-hypmtscheduler-zsrmv/hypmtscheduler_testkmod.c with mode=0 (which corresponds to base mixed-trust scheduler).

Some notes follow:

  1. Added new function uint32_t uapp_sched_mode_switch(struct sched_timer *task_timer) which switches the mode of the hyptask. Currently just returns the current mode (i.e., mimics mixed-trust scheduler with no modes) but can be adapted to suit requirements.

  2. Revised uapp_sched_run_hyptasks to invoke uapp_sched_mode_switch either before or after the hyptask execution based on the hyptask_modeswitch_flag that was passed to create the timer mode via hypmtscheduler_hyptaskaddmode within subtask (5) in the post above.

  3. Revised uapp_sched_process_timers to reprogram timer taking into account mode switches…

If I have a working uxmhf with raspbery pi, Do I need to recompile the raspbian or I can just recompile and resintall the HV.?

Reinstalling the HV should be sufficient. You don’t have to recompile the kernel.

Make sure you are using the aforementioned branch as linked in the OP when rebuilding the HV

Also when you are building the HV use the following options to the ./configure script during the build process:

./configure --enable-fiqreflection --enable-debug-uart --enable-uart-mini  --enable-uapp-hypmtscheduler

Note: The above assumes that you are using the mini UART. If you are using the full PL011 UART, replace --enable-uart-mini with --enable-uart-pl011 in the above command

In the past I use the '–with-boot-partition-start=8192 --with-boot-partition-end=137215" options for the configure command. Do I still need to do this (my start and end sectors where different than the defaults)?

4 posts were split to a new topic: Changing forum theme/color/preferences

In the cmdline.txt I also added the “maxcpus=1” that should still work right?

Yes, that should work. I tested with the same on my side.

OK. It compiled, boot it, and when I loaded the zsrmv.ko it froze.

To compile the zsrmv.ko module I copied:


to my zsrmv kernel module “src” directory
and change the line in hypmtscheduler_kmodlib.c :

include <hypmtscheduler.h>


include “hypmtscheduler.h”

and recompile.

Any thoughs?

Can you try with the zsrmv module without multi-mode capability to get a baseline of whether the original mixed-trust implementation works?

I tested the current version of the zsrmv.ko module on the previous version of the xmhf and it worked. This zsrmv.ko has code to exercise the modes but it is not used (or has hypercalls to create modes in the hv). My previous successful test used an old application test with a couple of mixed-trust tasks.

In summary

New zsrmv.ko with old xmhvf works
New zsrmv.ko with new xmhvf freezes.

Do you have a different combination in mind?

Ok let us try a few combinations. First, can you please try the zsrmv on the vanilla mixed-trust hyperscheduler PR here: überXMHF (rpi3-armv8_32): Add mixed-trust scheduler üapp and MAVLINK serial-heartbeat protocol üapp

If you have cloned https://github.com/amitvasudevan/uberxmhf.git then do the following:

git fetch -a
git checkout -b feature-uapp-hypmtscheduler origin/feature-uapp-hypmtscheduler

Then build the HV using the same configure options as we discussed above. This should correspond to the old uberXMHF that you have zsrmv working on. This will give us a baseline to start debugging from…