|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [RFC PATCH] xen/arm: Rebranding dom0less feature
On Fri, 7 Jul 2023, Christopher Clark wrote: > +CC openxt, Jason, Marek > > On Fri, Jul 7, 2023 at 2:06 PM Christopher Clark > <christopher.w.clark@xxxxxxxxx> 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.stabellini@xxxxxxx> wrote: > On Thu, 6 Jul 2023, George Dunlap wrote: > > On Wed, Jul 5, 2023 at 11:14 PM Stefano Stabellini > <stefano.stabellini@xxxxxxx> wrote: > > On Wed, 5 Jul 2023, George Dunlap wrote: > > > On Mon, Jul 3, 2023 at 9:55 PM P S <pairspace@xxxxxxxxx> > wrote: > > > > On Jul 3, 2023, at 15:45, Luca Fancellu > <luca.fancellu@xxxxxxx> wrote: > > > > > > > >> On 3 Jul 2023, at 18:48, Stefano Stabellini > <sstabellini@xxxxxxxxxx> 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.cooper3@xxxxxxxxxx> 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.fancellu@xxxxxxx> > > > >>>>>> --- > > > >>>>>> 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 Christopher, Daniel and all! So if I understand correctly, you are in favor if renaming Dom0less to Hyperlaunch throughout the Xen codebase? And we need a clarification of the docs/, especially docs/features/dom0less.pandoc?
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |