Xen project Mailing List

+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 again,

Christopher

Re: [RFC PATCH] xen/arm: Rebranding dom0less feature