[RFC] Linux-less boot

61 views
Skip to first unread message

Angelo Ruocco

unread,
Mar 27, 2020, 7:41:09 AM3/27/20
to Jan Kiszka, Peng Fan, jailho...@googlegroups.com, Marco Solieri, Luca Miccio, Alice Guo
Hi Jan, Peng, all,

We currently have a better understanding of Peng's work [1] and manage
to somewhat reproduce his results on another NXP board, the IMX8QM.
Since you showed interest in this, we would like to start implement
something a bit more portable and user-friendly.

In this regard, I would like to share some design choices:
- Jailhouse image stays more or less the same, all the code is added
into a loader, expanding Peng's work to make it more portable (across
Arm v8 boards for now) and generic. The loader will boot and init
everything that jailhouse and the inmates need. Without the loader
jailhouse can be started exactly like it was before.
- The loader is platform-specific, and thus it's necessary, at
compile-time, to have a parameter that specifies the target (something
like `BOOT=` or `TARGET=`), using the root-cell information to fill
the correct addresses and compile only the necessary drivers. Without
the parameter, the loader is not compiled.
- There is going to be a "sync" function at some point, probably when
loading the module, that can update the status of jailhouse so that
the cells created at boot time are controllable. The idea is to have
the same situation as if jailhouse was started with the `enable`.

Finally, we would also like to hear from Peng, to understand his
current plan so that we don't step in each other's toes.

[1] https://groups.google.com/forum/#!topic/jailhouse-dev/IZEFz-e2lh4

Angelo

Jan Kiszka

unread,
Mar 27, 2020, 8:45:56 AM3/27/20
to Angelo Ruocco, Peng Fan, jailho...@googlegroups.com, Marco Solieri, Luca Miccio, Alice Guo
On 27.03.20 12:41, Angelo Ruocco wrote:
> Hi Jan, Peng, all,
>
> We currently have a better understanding of Peng's work [1] and manage
> to somewhat reproduce his results on another NXP board, the IMX8QM.
> Since you showed interest in this, we would like to start implement
> something a bit more portable and user-friendly.
>
> In this regard, I would like to share some design choices:
> - Jailhouse image stays more or less the same, all the code is added
> into a loader, expanding Peng's work to make it more portable (across
> Arm v8 boards for now) and generic. The loader will boot and init
> everything that jailhouse and the inmates need. Without the loader
> jailhouse can be started exactly like it was before.

That is at least the best first step. We can still look into potential
consolidation (at the price of deviating the hypervisor startup) later
on. One area would be the hand-over mode of the CPUs (EL2 rather than
EL1 + EL2-stub).

> - The loader is platform-specific, and thus it's necessary, at
> compile-time, to have a parameter that specifies the target (something
> like `BOOT=` or `TARGET=`), using the root-cell information to fill
> the correct addresses and compile only the necessary drivers. Without
> the parameter, the loader is not compiled.

What would make the loader platform specific beyond what could be
configured and, thus, runtime selected by the root-cell config (or even
a device tree)?

> - There is going to be a "sync" function at some point, probably when
> loading the module, that can update the status of jailhouse so that
> the cells created at boot time are controllable. The idea is to have
> the same situation as if jailhouse was started with the `enable`.

Yes, we could make the used cell configurations available to the Linux
driver in order to virtually replay (for its internal state) what the
loader already did.

>
> Finally, we would also like to hear from Peng, to understand his
> current plan so that we don't step in each other's toes.
>
> [1] https://groups.google.com/forum/#!topic/jailhouse-dev/IZEFz-e2lh4
>
> Angelo
>

Thanks,
Jan

Peng Fan

unread,
Mar 27, 2020, 9:13:16 AM3/27/20
to Angelo Ruocco, Jan Kiszka, jailho...@googlegroups.com, Marco Solieri, Luca Miccio, Alice Guo
Hi Angelo,

> Subject: [RFC] Linux-less boot
>
> Hi Jan, Peng, all,
>
> We currently have a better understanding of Peng's work [1] and manage to
> somewhat reproduce his results on another NXP board, the IMX8QM.

Good.

> Since you showed interest in this, we would like to start implement something
> a bit more portable and user-friendly.
>
> In this regard, I would like to share some design choices:
> - Jailhouse image stays more or less the same, all the code is added into a
> loader, expanding Peng's work to make it more portable (across Arm v8
> boards for now) and generic. The loader will boot and init everything that
> jailhouse and the inmates need. Without the loader jailhouse can be started
> exactly like it was before.
> - The loader is platform-specific, and thus it's necessary, at compile-time, to
> have a parameter that specifies the target (something like `BOOT=` or
> `TARGET=`), using the root-cell information to fill the correct addresses and
> compile only the necessary drivers. Without the parameter, the loader is not
> compiled.

I am not sure about x86. But for AARCH64 and RISC, let uboot pass
a table to the loader, the table contains all platform specific things. The format
should be defined by jailhouse community.

Or use device tree, but that means needs to import libfdt to jailhouse.

> - There is going to be a "sync" function at some point, probably when loading
> the module, that can update the status of jailhouse so that the cells created at
> boot time are controllable. The idea is to have the same situation as if
> jailhouse was started with the `enable`.

Agree.

>
> Finally, we would also like to hear from Peng, to understand his current plan
> so that we don't step in each other's toes.

Ah. I was crazy busy in the past days on some remoteproc work, so stop the
Loader work for a while. but the other work will be done in a few days, and
I will back to this:)

Actually this feature is planned in our software release, and I need to have
the loader related stuff checked in NXP tree in the end of April.

My planned stuff are:
arm32+arm64 inmate cell with arm64 jailhouse.
Real cache color with Linux root cell + one inmate cell, and considering fit
jailhouse into SRAM.
As you listed, userspace tool support.
Considering MMU for loader. But not sure this really needed currently.

It is good we could reuse the work between, but not sure I could wait
until then, because I have a tight schedule.

Thanks,
Peng.

>
> [1]
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups
> .google.com%2Fforum%2F%23!topic%2Fjailhouse-dev%2FIZEFz-e2lh4&d
> ata=02%7C01%7Cpeng.fan%40nxp.com%7C8ae0f1ab40054707b2af08d7d24
> 3be6f%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6372090607
> 11306332&sdata=r8uxIgLOTqIMydWTlo6rDdaerSPd12MRnURPIUDA9X0
> %3D&reserved=0
>
> Angelo
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jailhouse" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jailhouse-de...@googlegroups.com.
> To view this discussion on the web visit
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups
> .google.com%2Fd%2Fmsgid%2Fjailhouse-dev%2FCADiTV-1QiRhSWZnw%252
> BkHhJMO-BoA4sAcOmTkQE7ZWbHkGh3Jexw%2540mail.gmail.com&dat
> a=02%7C01%7Cpeng.fan%40nxp.com%7C8ae0f1ab40054707b2af08d7d243b
> e6f%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637209060711
> 306332&sdata=L4PCq2Lo6FlAqzw%2FhPr0p7dhtG3DrOsfRl%2BBtBV7lA
> w%3D&reserved=0.

Nikhil Devshatwar

unread,
Mar 27, 2020, 11:20:05 AM3/27/20
to Peng Fan, Angelo Ruocco, Jan Kiszka, jailho...@googlegroups.com, Marco Solieri, Luca Miccio, Alice Guo
Hi,


On 27/03/20 6:43 pm, Peng Fan wrote:
Hi Angelo,

Subject: [RFC] Linux-less boot

Hi Jan, Peng, all,

We currently have a better understanding of Peng's work [1] and manage to
somewhat reproduce his results on another NXP board, the IMX8QM.
Good.

Since you showed interest in this, we would like to start implement something
a bit more portable and user-friendly.

In this regard, I would like to share some design choices:
- Jailhouse image stays more or less the same, all the code is added into a
loader, expanding Peng's work to make it more portable (across Arm v8
boards for now) and generic. The loader will boot and init everything that
jailhouse and the inmates need. Without the loader jailhouse can be started
exactly like it was before.
- The loader is platform-specific, and thus it's necessary, at compile-time, to
have a parameter that specifies the target (something like `BOOT=` or
`TARGET=`), using the root-cell information to fill the correct addresses and
compile only the necessary drivers. Without the parameter, the loader is not
compiled.
I am not sure about x86. But for AARCH64 and RISC, let uboot pass
a table to the loader, the table contains all platform specific things. The format
should be defined by jailhouse community.

I had tried to prototype the type1 jailhouse bootloader long time back. [1]
I used a python script [2]  to describe all the images needed for loading the different cells.
It might be different files for Linux, baremetal inmates, etc

Based on the arguments, python script generates a data structure [3]  which loader can understand.
I also generated a linker script which packaged all the binaries in single elf. But that can be ignored.


[1] https://github.com/nikhildevshatwar/jailhouse/commit/6883c0a0b1e4cd12e8097cb656262f6d9b2fb4b1
[2] https://github.com/nikhildevshatwar/jailhouse/blob/devel/type1-poc-upstream/tools/jailhouse-loader.py
[3] https://github.com/nikhildevshatwar/jailhouse/blob/devel/type1-poc-upstream/loader.h

Regards,
Nikhil D
Reply all
Reply to author
Forward
0 new messages