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

[Stefano Stabellini <stefano.stabellini@xxxxxxx>]

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.