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

[Julien Grall <julien@xxxxxxx>]

Hi,

On 06/07/2023 14:04, Luca Fancellu wrote:
> > > > > 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.
> > > Personally, I like the name “Hyperlaunch DT”, because it tells me that we are 
> > > launching VMs and the DT is involved, if I understood correctly the design,
> > > it would be the same also on x86 (and in every architecture that will come later) so being 
> > > “Hyperlaunch DT” an arch agnostic name makes it a good
> > > candidate for phase out dom0less name and for the future when a common code 
> > > will use the DT to launch VMs at Xen boot.
> > I assume that DT means Device-Tree here. If so, I find a name a bit misleading 
> > because we are talking about the way to pass the configuration rather than what 
> > the feature is doing.
> >
> > My assumption here is that a DomB solution would still use the Device-Tree to 
> > describe the domains.
> The sentence below makes sense to me, “DT”, “domB/Boot/Boot Domain/BD”, “Measured 
> Boot/MB” can do the work of distinguish the functionalities, even if the Device tree is involved in all of them.
Throwing another name we discussed today at the pub. How about: 
"Hyperlaunch static"
This would indicate the domains have been statically configured whereas 
I guess the one from DomB may be more dynamic?
--
Julien Grall