+CC openxt, Jason, Marek On Fri, Jul 7, 2023 at 2:06 PM Christopher Clark < christopher.w.cl...@gmail.com> wrote:
> +CC members of the Hyperlaunch Working Group + participants on earlier > Hyperlaunch threads > > On Thu, Jul 6, 2023 at 2:39 PM Stefano Stabellini < > stefano.stabell...@amd.com> wrote: > >> On Thu, 6 Jul 2023, George Dunlap wrote: >> > On Wed, Jul 5, 2023 at 11:14 PM Stefano Stabellini < >> stefano.stabell...@amd.com> wrote: >> > On Wed, 5 Jul 2023, George Dunlap wrote: >> > > On Mon, Jul 3, 2023 at 9:55 PM P S <pairsp...@gmail.com> wrote: >> > > > On Jul 3, 2023, at 15:45, Luca Fancellu < >> luca.fance...@arm.com> wrote: >> > > > >> > > >> On 3 Jul 2023, at 18:48, Stefano Stabellini < >> sstabell...@kernel.org> wrote: >> > > >> >> > > >>> On Mon, 3 Jul 2023, Daniel P. Smith wrote: >> > > >>> On 7/1/23 11:13, Luca Fancellu wrote: >> > > >>>>> On 1 Jul 2023, at 08:53, Andrew Cooper < >> andrew.coop...@citrix.com> wrote: >> > > >>>>> >> > > >>>>> On 30/06/2023 10:12 am, Luca Fancellu wrote: >> > > >>>>>> The "dom0less" feature was intended to be the >> feature where a domU >> > > >>>>>> domain could be launched without the control >> domain (Dom0) >> > > >>>>>> intervention, however the name seems to suggest >> that Dom0 cannot >> > > >>>>>> be part of the configuration, while instead it's a >> possible use case. >> > > >>>>>> >> > > >>>>>> To avoid that, rename the "dom0less" configuration >> with the name >> > > >>>>>> "hyperlaunch", that is less misleading. >> > > >>>>>> >> > > >>>>>> Signed-off-by: Luca Fancellu < >> luca.fance...@arm.com> >> > > >>>>>> --- >> > > >>>>>> This is an RFC to get the feeling of the community >> about the name >> > > >>>>>> change, for now it's everything in one patch just >> to see how it >> > > >>>>>> will look like, if there is interest on proceeding >> into it, I can >> > > >>>>>> split in more commit. >> > > >>>>> >> > > >>>>> Have you discussed this with Dan and Chris at all? >> You haven't even >> > > >>>>> CC'd them. >> > > >>>> >> > > >>>> No, this rename idea started from a chat during the >> summit, anyway Julien >> > > >>>> promptly add them to the CC, because I forgot. >> > > >>> >> > > >>> No worries and thank you for considering and taking >> the time to do this RFC. >> > > >>> It is greatly appreciated that there is a strong >> willingness to have dom0less >> > > >>> and hyperlaunch merged. >> > > >>> >> > > >>>>> >> > > >>>>> While there is a lot of end-goal in common between >> the dom0less and >> > > >>>>> hyperlaunch, and that the name dom0less is deeply >> misleading, >> > > >>>>> hyperlaunch is specifically not this. >> > > >>>> >> > > >>>> Yes Hyperlaunch is more than this, however as I >> said, with this RFC I would >> > > >>>> like >> > > >>>> to ear opinions, @Daniel @Christopher could it be a >> proper name for the >> > > >>>> dom0less >> > > >>>> feature? >> > > >>> >> > > >>> As Andy has alluded, hyperlaunch is meant to provide >> a flexible means to >> > > >>> handle domain construction at boot to meet a wide >> range of possible use cases. >> > > >>> One of those use cases is dom0less, so yes, >> ultimately what dom0less does >> > > >>> today will be achievable under hyperlaunch. Our >> intended approach to align the >> > > >>> two implementations is one that is meant to be >> minimally disruptive, since >> > > >>> dom0less is considered a supported (SUPPORT.md) >> capability. As mentioned, we >> > > >>> are greatly appreciative to the openness to adopt the >> name, >> > > >> >> > > >> Thanks Daniel! >> > > >> >> > > >> >> > > >>> but a big concern >> > > >>> I personally have is the confusion it could cause a >> general user. A blanket >> > > >>> rename would end up with two documents in the docs >> tree that provide two >> > > >>> different explanations of hyperlaunch and two >> different device tree >> > > >>> definitions. So I think a more measured approach >> should be considered here. >> > > >>> >> > > >>>> If this patch makes things more difficult for the >> Hyperlunch serie, I’m ok >> > > >>>> to drop it, >> > > >>>> my only aim was just to find a less misleading name >> for the feature. >> > > >>> >> > > >>> What I would like to suggest as a good first step >> would be an update to the >> > > >>> dom0less document. Provide a note at the beginning >> that points to the >> > > >>> hyperlaunch design doc as a more general approach >> that will eventually subsume >> > > >>> dom0less. This would provide a gentler transition for >> exist users of dom0less. >> > > >>> >> > > >>> If it is not too much, I would also ask, please have >> a look at the design for >> > > >>> boot modules in the series Christopher just posted. >> The design pulls from the >> > > >>> work done by dom0less and expanded upon it. I major >> step into merging the two >> > > >>> capabilities will be to have a common set of >> structures. Once those are in >> > > >>> place, we can move to a common device tree >> representation, and at that point >> > > >>> we would be fairly close, if not at the point of a >> formal merger of between >> > > >>> the two. >> > > >> >> > > >> At the moment we have a concrete problem with >> explaining dom0less and >> > > >> hyperlaunch to potential new users. Using two >> different names for a >> > > >> similar feature on arm and x86 causes confusion. It is >> hurting Xen as a >> > > >> solution. Personally I already had to switch to use >> the word >> > > >> "hyperlaunch" for everything in my users-facing >> presentations. >> > > >> >> > > >> At the summit, we discussed that it would be a good >> idea to use a single >> > > >> name to refer to both features on arm and x86. Given >> that "dom0less" >> > > >> causes additional issues because it makes people think >> that there is no >> > > >> Dom0, the suggestion was to use "hyperlaunch" to refer >> to both features. >> > > >> >> > > >> We don't need to 100% align the two implementations >> and data structures. >> > > >> This is not for engineers that are going to look at >> the specifications >> > > >> and improve them. This is for users/customers of Xen >> that are trying to >> > > >> understand what the hypervisor enables them to do. We >> need to be able to >> > > >> show users architecture slides with the same name and >> explanation on >> > > >> both ARM and x86. >> > > >> >> > > >> I am sure that Daniel and Christopher remember, but >> for the others on >> > > >> this email thread, the name "hyperlaunch" was born >> exactly to be that: >> > > >> the one name to cover both features on ARM and x86 >> even if they have a >> > > >> different implementation. Appended an old email for >> reference. >> > > >> >> > > >> Also I agree with Daniel that we need to be careful >> about the two docs >> > > >> under docs/. I think he is right we need to add a >> paragraph explaining >> > > >> the history and a pointer to the other document. >> Something like: >> > > >> >> > > >> "Dom0less is the name that was used when initially >> introducing the >> > > >> feature on ARM. Then, the "dom0less" name was retired >> in favor of >> > > >> "hyperlaunch" to avoid confusion (a Dom0 might still >> be present) and to >> > > >> align with x86 (where a similar feature was called >> hyperlaunch from the >> > > >> start)." >> > > > >> > > > I’m fully ok to add a section like this pointing to the >> Hyperlaunch design. >> > > >> > > _If_ this text is added, please include links/references >> to the Hyperlaunch wiki page and Hyperlaunch design docs. >> > > >> > > > @Daniel and @Christopher would it be ok for you or the >> changes in the serie >> > > > are going to be problematic for your future work? In >> the end it’s just a mechanical >> > > > rename, so I guess we just need to agree on naming >> conventions. >> > > >> > > Please see the history of trademark litigation about the >> use of symbolic names to reference similar-but-different >> > artifacts. >> > > It is much easier to use the same name to refer to >> entirely different objects. Historically, confusion arises when a >> > name is >> > > used in similar contexts. >> > > >> > > There is also versioning. Could we refer to dom0less as >> "Hyperlaunch Version -1"? >> > > >> > > How about renaming dom0less to "Hyperlaunch Lite"? >> > > >> > > >> > > Perhaps it would be helpful if you could explain more clearly >> your concerns. I take it that you want a name which can be >> > used specifically >> > > to indicate the full "domB measured boot" functionality that >> was Daniel and Christopher's original goal, and that you're >> > afraid that using >> > > plain "Hyperlaunch" for only the "start VMs from Xen on boot" >> functionality will dilute that? >> > > >> > > The "start VMs from Xen on boot" functionality is the *only* >> thing that a big chunk of the users of this functionality want; >> > referring to >> > > it as "Hyperlaunch Lite" or "Hyperlaunch -1" will undermine the >> value of the functionality. >> > > >> > > What if we use "Measured Hyperlaunch", or "Hyperlaunch Measured >> Boot" to refer to the full measured boot functionality? >> > >> > I think this is the best way. >> > >> > >> > > Or, "Hyperlaunch DT" for "Booting VMs from Xen using Device >> Tree" (without the involvement of a domB), "Hyperlaunch Boot >> > Domain / >> > > Hyperlaunch domB" for a more general "domB" functionality, and >> "Hyperlaunch Measured Boot" for the full functionality >> > (assuming there's >> > > more to this than simply having a domB involved)? >> > >> > >> > We need an overarching name to cover the feature "start VMs from >> Xen on >> > boot" on both ARM and x86. From my understanding and from the >> original >> > emails on the subject, the name "hyperlaunch" was it. >> > >> > >> > Sure; but think "guitar" vs "acoustic guitar" vs "electric guitar". >> "Electric guitar" is new, "guitar" covers them both, but you sometimes >> > need a way to specify "acoustic". Right now target configurations >> we're talking about include: >> > >> > 1. Booting all your domains directly from Xen using DT configurations >> > 2. Booting a domB, which then executes some more complicated >> programmatic configuration to launch VMs before disappearing >> > 3. Doing full measured boot on the whole system using a domB. >> > >> > If "Hyperlaunch" means 1-3, we not only need a way to specify that >> you're talking about 3, but *also* a way to specify that you're talking >> > about 1. In the vast majority of cases for the foreseeable future >> are going to be 1. Additionally, we want to make sure that >> > "Hyperlaunch" *actually* turns out to mean 1-3, and not just 1. >> > >> > The thing I like about "Hyperlaunch DT" is that to me it sounds pretty >> cool but also is very descriptive: I haven't talked to people >> > building these systems, but it seems like saying, "The hypervisor >> launches VMs based on a Device Tree passed to it at boot" will be >> > immediately understood, and stick in people's minds. >> > >> > So maybe informally, or in "short usage" use "Hyperlaunch", but in >> documentation or reference systems, when talking specifically about #1, >> > try to use "Hyperlaunch DT", just to reinforce the idea that there's >> more to Hyperlaunch that's coming down the road? >> >> "Hyperlaunch DT" would refer to both the x86 and ARM implementations >> because they are both based on DT. >> >> I think it is better than "Hyperlaunch Lite" but I am not a fan of >> either of these two names because "DT" and "Lite" get easily lost in >> presentations and discussions. For the next few years many will talk >> about HyperLaunch just to refer to what is Dom0less today. So if the >> goal when we say "HyperLaunch" is to bring Measure Boot or XSM to >> people's minds, I don't think this will work well. >> >> If we want to keep "Hyperlaunch" to mean 1-3 above, highlighting Measure >> Boot or XSM, then I think we should consider using "Dom0less" for 1. >> Yes, it is misleding, but at least it is unique, and a google search for >> "dom0less" leads the user to the right results. >> >> If we do that, we should rename "Hyperlaunch" with "Dom0less" in >> docs/designs/launch/hyperlaunch.rst. That's because "Hyperlaunch" is >> defined as "the ability of a hypervisor to construct and start one or >> more virtual machines at system launch in a specific way", which falls >> under Dom0less in this discussion. >> >> In my opinion, it is better to have specific names for specific >> features. So I would use "HyperLaunch" to mean "the ability of a >> hypervisor to construct and start one or more virtual machines at system >> launch in a specific way" as it is defined today. >> >> When we add Measure Boot or XSM or other security/safety features, I >> would call them out specifically. For instance, "HyperLaunch with XSM". >> It is more descriptive and highlights each feature. >> >> Note that at AMD we'll need HyperLaunch without an all-powerful Dom0, >> probably with XSM. So I am not writing this because I don't think the >> other features 2-3 are not important. They definitely are important. > > > > Thanks to all the participants in this thread for the interest in > Hyperlaunch and > the support for enabling common advanced boot functionality for Xen across > architectures. > > I'm aiming to provide here a hopefully-fairly-objective overview of the > issues > being raised so that we can ensure that these are covered, and then I will > also > give my views afterwards. > > ------------------------------------------------------------ > = Naming and communication > > - Ensuring expectations are set correctly for the Hyperlaunch name > - communicating the value of it, differentiation for Xen > - avoiding sub-branding it for feature subsets, use cases, technologies > > - Retiring the term 'dom0less' > > - How to describe the "starting multiple VMs at host boot" functionality > > - How to describe further Hyperlaunch functionality beyond this > - eg. isolation properties and relevance to critical systems > - eg. running without a classic dom0 > > - How Hyperlaunch relates to other boot functionalities and > technologies, > including: > - architecture-specific aspects and architecture-neutral aspects > - Device Tree > - boot domain > - control domain, hardware domain, dom0 > - domain builder > - system measurement > - XSM > - DRTM > - etc. > > > = Migration > > - Providing a forward path for existing users of dom0less functionality > across the technical changes for Hyperlaunch cross-architecture > implementation > - document compatibility > - support a "dom0less mode" with existing Device Tree structure > - documentation updates to be paired with progress on code > implementation > > > = Community resourcing > > - Supporting code review and merge of Hyperlaunch changes into Xen > - transitioning existing Arm logic into common, including FDT > > - Provision of accurate, consistent documentation materials to support > effective communication to existing and prospective users, developers and > other > stakeholders > - Ensuring that the document structure supports ongoing maintenance: > - Multiple use cases, structure docs accordingly: eg. > - use case: static partitioning, critical + non-critical VMs > - use case: measured launch with a boot domain > - use case: fast VM start for embedded systems > - Architecture of Hyperlaunch, relevance to other hypervisors > - nested systems > > - Design, review and agreement for common cross-architecture and > arch-extensible interfaces, including: > - common boot data structures > - Device Tree structure > - hypfs entries > - introspection to determine hyperlaunched system status > > - Development of test cases > > - CI of Hyperlaunch interfaces, to ensure that it stays working > > ------------------------------------------------------------ > > Views arrived at in discussion with Rich and Daniel, and after reading the > thread contributions, follow this point. > > "Hyperlaunch" is to be the common name across architectures for a flexible, > configurable boot system for coordinating the launch of multiple VMs by the > hypervisor, with a common implementation, pooling resources and development > risk across the Xen community. The interfaces are core to it. > > From the Hyperlaunch design document (reviewed + committed to the tree): > > "The design enables seamless transition for existing systems that require > a dom0, and provides a new general capability to build and launch > alternative configurations of virtual machines, including support for > static partitioning and accelerated start of VMs during host boot, while > adhering to the principles of least privilege. It incorporates the existing > dom0less functionality, extended to fold in the new developments from the > Hyperlaunch project, with support for both x86 and Arm platform > architectures, building upon and replacing the earlier 'late hardware > domain' feature for disaggregation of dom0. > > Hyperlaunch is designed to be flexible and reusable across multiple use > cases, and our aim is to ensure that it is capable, widely exercised, > comprehensively tested, and well understood by the Xen community." > > https://xenbits.xen.org/docs/4.17-testing/designs/launch/hyperlaunch.html > > ie. Hyperlaunch was created to move away from point solutions that > hard-code > specific launch configurations, isolation properties and threat models. It > isn't just about starting domains -- it is about enabling the construction > of > complex use cases runtimes for Xen. It is the result of iterative design > starting with the disaggregation for the late hardware domain, through > dom0less development and then with the comprehensive hyperlaunch design and > implementation that builds upon them both. > > The current interest and investment in Hyperlaunch is driven by its > relevance > to Safety Critical systems due to the isolation properties and improvement > in the ability to certify the software -- this is closely related to but > slightly different from starting multiple VMs at host boot. > > To encourage commonality and allow for future development, we should not > use architecture-specific or vendor-specific name variations, and also > avoid > technology-specific name variations (eg. Device Tree or "DT"). > > Instead, the use case configurations should themselves be describable. > > Thanks again, > > Christopher > >
