(+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] 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? 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. -- 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/9e8f00b4-2a2d-8bb8-e92c-8e23e5910af0%40oth-regensburg.de.
