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.
