[svsm-devel] [RFC] task/schedule: Idle process?

[Roy Hopkins]

On Thu, 2023-09-07 at 10:47 +0200, Jörg Rödel wrote:
> Hi Carlos,
> 
> On Wed, Sep 06, 2023 at 09:29:00AM -0500, Carlos Bilbao wrote:
> > The PR for the scheduler (#64) is still under review. In traditional OSs,
> > it makes sense to include an idle userspace process that does nothing and
> > is always there to be scheduled. So I was wondering if we should do the
> > same for the SVSM.
> > 
> > Currently, SVSM schedules the "root" task responsible for running the
> > request loop. However, in the event of a SvsmReqError:FatalError, this
> > process may terminate prematurely. This raises the question: should we
> > introduce an idle process in SVSM, or is it irrelevant in that context?
> > 
> > My first intuition is that if we don't have an idle process, then the SVSM
> > itself would terminate, and perhaps that would difficult further debugging
> > of potential errors. Or maybe it would not?
> 
> Yes, we plan with an idle process. It will be the (kernel-only) process
> that gives control back to the guest OS by switching the VMPL.
> 
> The idea is that we have a runqueue and execute tasks from that as
> long as any of them is runable. Once no process is runable anymore the
> idle task is selected by the scheduler and switches back to the guest
> VMPL.
> 
> Regards,
> 
>         Joerg

I thought about incorporating an idle task into the current PR but until the
usage of tasks is a bit more mature and we start to support modules that
actually use tasks, it probably does not make sense to add an idle task yet.

I guess we could refactor the existing request_loop() function into its own task
and call this the 'idle task', allowing the entry point thread to return and
subsequently terminate and switch context. However, the request_loop() never
calls schedule() meaning the idle task will never cede execution. This is the
same behaviour as the current state of the PR but it is perhaps less obvious if
we call it an idle task.

Regards,
Roy