> Subject: Re: [PATCH 06/10] Add libbaremetal > > (+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?
No in my mind when I did this patchset. My idea was to minimize changes to hypervisor/* . Thanks, Peng. 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups > .google.com%2Fd%2Fmsgid%2Fjailhouse-dev%2F9e8f00b4-2a2d-8bb8-e92c- > 8e23e5910af0%2540oth-regensburg.de&data=02%7C01%7Cpeng.fan%4 > 0nxp.com%7Cba17f1e9b4e54ebd409f08d840639eaf%7C686ea1d3bc2b4c6fa > 92cd99c5c301635%7C0%7C0%7C637330143892122750&sdata=cP24P > MwWOKEDB8qefgoxm37hwFuEY4j27YM3IeDYAHg%3D&reserved=0. -- 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/DB6PR0402MB2760D40A6D6B336CF1F81803885F0%40DB6PR0402MB2760.eurprd04.prod.outlook.com.
