> On 6 Jul 2023, at 11:01, George Dunlap <george.dun...@cloud.com> 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.
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. > > 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? > > -George
