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@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

Hi,

On Fri Mar 24, 2017 at 22:48:03 +0100, Marc CHALAND wrote:

2017-03-22 23:45 GMT+01:00 Adam Lackorzynski adam@os.inf.tu-dresden.de:

...

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

So, in that case, I have to implement my own scheduler to run it into one vCPU ? We don't have the code of the old scheduler.

Ah, you don't have a scheduler. You don't need to use a vCPU, you can also use a thread with its known semantics. That still works as it used to work.

Adam

Hi,

On 03/27/2017 03:12 PM, Marc CHALAND wrote:

Hi

Le mer. 22 mars 2017 à 00:59, Adam Lackorzynski <adam@os.inf.tu-dresden.de mailto:adam@os.inf.tu-dresden.de> a écrit :

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.

Do you have any sample lua script to help me to set a linux vm up ?

Please have a look at conf/examples/l4lx.cfg in your l4 source directory. This starts the L4Linux kernel and passes a couple of arguments to the kernel such as memory size and the ramdisk name.

Best, Matthias.

Le lun. 27 mars 2017 à 15:59, Christian Ludwig christian_ludwig@genua.de a écrit :

Hi,

On Monday, 27. March 2017, 15:24:59 Matthias Lange wrote:

On 03/27/2017 03:12 PM, Marc CHALAND wrote:

...

<adam@os.inf.tu-dresden.de mailto:adam@os.inf.tu-dresden.de> a écrit : 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.

Do you have any sample lua script to help me to set a linux vm up ?

Please have a look at conf/examples/l4lx.cfg in your l4 source directory. This starts the L4Linux kernel and passes a couple of arguments to the kernel such as memory size and the ramdisk name.

I guess the question was more about running umodified Linux in a VM on top of Fiasco. In this scenario, Fiasco acts as the hypervisor only. There is the 'uvmm' package that implements a virtual machine monitor, which sets up a hardware-like environment for Linux. That package also has an example configuration.

That's it. Thank you Marc

On Thu Mar 30, 2017 at 14:42:36 +0000, Marc CHALAND wrote:

I did some tests and I'm stuck on bootstrap. I assume that omap (a15) and imx7 (a7) have the same switch_to_hyp mechanism.

No, they haven't. Those switching routines are there to switch from a lower-priv level to a higher one, i.e. must be privided by software running in Trustzone secure side. There's such functionality for the OMAP5, but for imx it's different.

a7 hangs exactly at that point. Any idea to fix this ?

Multiple. You need to make sure that u-boot boots you non-secure (there's no hyp-mode on the secure side). u-boot needs to be enabled for that functionality. It hopefully is. Make sure to use the uimage variant and boot with bootm. Also set "setenv bootm_boot_mode nonsec" to override a possible wrong default for this case here. Does this help already?

Adam

On Fri Mar 31, 2017 at 08:07:00 +0000, Marc CHALAND wrote:

Le jeu. 30 mars 2017 à 23:54, Adam Lackorzynski adam@os.inf.tu-dresden.de a écrit :

...

...

a7 hangs exactly at that point. Any idea to fix this ?

Multiple. You need to make sure that u-boot boots you non-secure (there's no hyp-mode on the secure side). u-boot needs to be enabled for that functionality. It hopefully is. Make sure to use the uimage variant and boot with bootm. Also set "setenv bootm_boot_mode nonsec" to override a possible wrong default for this case here. Does this help already?

I've tried unsec boot mode, but second core doesn't start. I guess this is also something with the switch to hyp stuff.

Good point. Probably other cores are booted into secure mode by u-boot, so we'd need to switching code ourselves.

Is it possible to have "detached" threads (like l4linux ones) on this linux ?

No.

Adam