On 14.08.20 17:06, Ralf Ramsauer wrote:
(+Cc Wolfgang, we recently had discussion on the boot process of Jailhouse)
On 8/14/20 11:43 AM, Jan Kiszka wrote:
On 14.08.20 11:08, Peng Fan wrote:
Subject: Re: [PATCH 06/10] Add libbaremetal
On 07.08.20 05:06, [email protected] wrote:
From: Peng Fan <[email protected]>
Add libbaremetal for sharing code between inmates and jailhouse
baremetal loader.
The Makefile code is copied from inmates, currently only string.c is
moved from inmates to libbaremetal. In future, we might need to share
uart/mmu and etc.
Might quickly become confusing to have two libs. What prevents renaming
inmates/lib completely into libbaremetal? Sure, there are some jailhouse
specifics in inmates/lib, but those could likely be put in some corner.
How about rename inmates to baremetal?
And add bootloader stuff under baremetal?
We could do
baremetal
What we provide is a minimalist runtime environment, which is not just
limited to baremetal applications (depends on the definition of
baremetal, though). But…
├── demo-inmates
├── lib
├── tests
└── tools
and put the jailhouse loader under tools. Inmates is a "brand" in
Jailhouse context, so it should remain in some form. But it's true, some
… yep, the branding is the point why we should keep calling them 'inmates'.
of the existing demo inmates can already run without jailhouse.
And that's the second point - we already have some kind of support for
this kind of use case. However, I agree that I wouldn't expect the
preloader inside inmates/.
Ralf, what do you think?
Peng, I just read the code of the loader and I try to understand what
how it's exactly working. Nice work! Do I see that correctly: You
basically "imitate" Linux in a way that you manually do the early setup
(some register setup, GIC init, kick off all CPUs, hv stubs, ...).
IOW, you bring the system to the same state, where the Linux driver
would hand over Jailhouse. You activate Jailhouse, we then return to the
loader which got lifted to the first cell, the root cell. Now you use
the loader to partition the system, i.e., to create cells. Therefore,
you use the hypercall interface, just like Linux would typically do it
for us. Finally, there's the hand over to Linux.
But do we really need a separate loader? Can't we just place the
loader-related stuff at, say, the end of jailhouse.bin?
To be more concrete, i think it should be possible to have the full
preloader-thing located under hypervisor/arch/arm64/. It should also be
possible to link everything that is required into jailhouse.bin - so we
would get one universal binary instead of a chain of dependent binaries. [1]
Interesting idea.
Pro: You can make early use of the UART in your preloader without having
the need to, for example, duplicate drivers. That's quite useful for
debugging if something goes wrong very early. Secondly, you can also
piggyback on existing gic routines, no need to reimplement
phys_processor_id, …
The next thing after early boot would be the handover to jailhouse.
Before the handover, we set a flag that indicates that we do an early
boot of Jailhouse. We can use this flag to do the full partitioning of
the system before we return to the guests in one single step. IOW, we
never return to the preloader once the handover happened. We can do
that, as u-boot already placed our guests and we just need to start them
(as we would start regular cells).
The amount of additional logic in the actual hypervisor core should be
reasonably low.
Did you already consider that strategy? Jan, what do you think?
As we are already in visionary phase... There is another use case to
consider:
I'd like to have a Jailhouse variant that comes without a root cell.
That means, we will need a booting procedure that creates all cells,
loads and starts them - and then drops all the logic that could
configure or destroy them (or never includes it in the first place -
build-time setting). This should reduce the Jailhouse runtime code to
much less than 10K LoC.
Peng's approach is useful in case you do want to keep the flexibility to
reconfigure the system from a root cell, just like you can do when
booting via Linux. The idea of adding a preloader is minimal invasive to
the existing setup. My root-less mode will be maximal invasive, though.
If root-less would be sufficient for cases you do not want Linux-based
boot, we can skip this approach and head for root-less full steam.
If there are use cases for all three variant, we can try to look for
common pieces in the two Linux-free options. My root-less mode would
also need a single-step "create and start all cells", e.g. And your idea
to include the bootstrap logic into an init section of jailhouse.bin is
also attractive for both.
Jan
Thanks
Ralf
Jan
[1] E.g., we could group early preloader bootup code to an own section
that we drop once it's not needed any longer.
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/jailhouse-dev/5cd1415a-f4d0-b307-e81a-769b7be8eebb%40siemens.com.
