Questions about Fiasco.OC scheduler and L4Linux

[Adam Lackorzynski]

Hi Marc,

On Wed Mar 22, 2017 at 15:50:34 +0000, Marc CHALAND wrote:
> Le mer. 22 mars 2017 à 00:59, Adam Lackorzynski <adam at os.inf.tu-dresden.de>
> a écrit :
> 
> > On Tue Mar 21, 2017 at 08:31:06 +0100, Marc CHALAND wrote:
> > > I'm doing a study to port old software on top of Fiasco.OC. This soft uses
> > > routines which blocks thread scheduling between EnterRegion and
> > LeaveRegion
> > > call. Is there any equivalent on TUDOS ? Did somebody already get this
> > > challenge ?
> > 
> > Yes, that's what the vCPU model is basically about, i.e. supporting
> > execution style of an OS. With this you can have EnterRegion and
> > LeaveRegion by disabling/restoring virtual interrupts.
>
> Is thread scheduling managed by virtual interrupts ? If I disable virtual
> IRQ, no other thread will get time slot ?
> L4Re documentation about vCPU is very short and I don't understand how it
> works.

Basically the vCPU model is an asynchronous execution model, that is
very similar to an actual CPU. I.e. you have vCPU that executes code and
that has an entry vector that is being jumped to whenever the vCPU shall
get an event (both asynchronous interrupts and synchronous exceptions).
To prevent diverting to the entry code there's a virtual interrupt flag,
i.e. if virtual interrupts are off, no message/interrupt will be posted.
Based on that multi-threading in the vCPU is implemented, i.e. some
timer triggers an interrupts, which in turn triggers some scheduling
code running in the vCPU which in turn does some stack switching.
You can also look into this paper
http://os.inf.tu-dresden.de/papers_ps/rtlws2010_genericvirt.pdf

> > > I would like to know if L4Linux uses Fiasco.OC scheduler or a user land
> > one
> > > ?
> > 
> > It uses Linux's own scheduler.
> 
> So how are scheduled hybrid/alien tasks?

With the vCPU model this has indeed gotten more involved. As a vCPU is
just a single execution object (thread) to the microkernel, there cannot
be any distinction made. This is contrary to the previous thread-based
mechanism in L4Linux. However, I guess this is a pretty niche thing
and not so important, is it? Still you could skim through
http://os.inf.tu-dresden.de/papers_ps/ospert2016-predicatble-execution.pdf

> How are the priorities managed
> between L4Re threads and L4Linux ones ?

The L4Linux threads run all within a vCPU and thus are not visible
outside / to the microkernel, i.e. a vCPU has an L4 prio as any other L4
thread in the system.

> > > For our i.MX7d board, Freescale provides Linux drivers on 4.1. I don't
> > know
> > > yet how many drivers we will need. Do you think it is better to port
> > > drivers from 4.1 to L4Linux 4.3 or later or get a L4Linux 4.1. I have no
> > > idea about the complexity on doing this.
> > 
> > With a i.MX7d you have hardware support for virtualization, so what
> > about using that, i.e. running normal Linux in a VM? Getting an L4Linux
> > for an older version is of course possible but a bit of work.
> 
> In that case, is it possible to give hardware access to vm without need to
> emulate it ?

Yes but that's the same for this type of VM and L4Linux. In both you can
pass-through MMIO and interrupts to give them direct access to devices.

> I've never used this technology yet. I don't know how it works
> in L4Re.

I'm sure you've heard e.g. about Intel VT, or ARM's Virtualization
Extensions. Those are CPU features that basically allow you to
efficiently(!) execute OS kernels deprivileged, by providing another
layer of address translation and proper CPU exception handling. OSs
need to integrate those mechanism to run unmodified guest kernels.
In L4Re this is also mapped to a vCPU which however has more state.
The virtual platform is provided by a VMM component.

> How are managed the priorities between linux threads and L4Re ones
> ?

This is the same answer as above.

> Is communication possible between a virtualized linux task and a L4Re
> native one ?

Yes, although this would likely go through the guest kernel, i.e.
requires a driver in the guest OS (or uses one that is already there).


Adam