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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Sat, 8 Jul 2023, Rich Persaud wrote:
> On Jul 8, 2023, at 03:29, Luca Fancellu <luca.fancellu@xxxxxxx> wrote:
> > 
> >>>> 
> >>>> Instead, the use case configurations should themselves be describable.
> >>> 
> >>> Thanks Christopher, Daniel and all!
> >>> 
> >>> So if I understand correctly, you are in favor if renaming Dom0less to
> >>> Hyperlaunch throughout the Xen codebase? And we need a clarification of
> >>> the docs/, especially docs/features/dom0less.pandoc?
> >> 
> >> Christopher wrote:
> >>>> = Community resourcing
> >> 
> >> Note the pre-requisite work items for upstream Xen, listed under 
> >> "Community Resourcing", to merge code for Hyperlaunch common interfaces 
> >> and test cases, with docs on configuration of Hyperlaunch to deliver 
> >> functionality for dom0less use cases.
> > 
> > Are you saying that before renaming the “dom0less” feature, we should wait 
> > for it to be ported to the common code?
> 
> Why "wait"? In what timeframe do you expect dom0less to use Hyperlaunch code?
> 
> Can kernel component foo adopt the name of kernel component bar without code 
> change?
> 
> Can dom0less stakeholders derive Hyperlaunch benefits without using 
> Hyperlaunch code?


I think Rich is saying that before using the same name we should make
sure that the interfaces and features are actually comparable and maybe
even "compatible". I think that is very reasonable. Rich, did I
understand correctly?


The Hyperlaunch (x86) code is not yet upstream, but the design document
that describes the device tree interface shows an interface that is very
similar, almost compatible, with today's dom0less (ARM) device tree
interface.

The structure of the device tree information is the same. Going through
it I could only spot only tiny differences:
- top level node is "hypervisor" instead of "chosen"
- "module-addr" instead of "reg"
- "module,kernel" instead of "multiboot,kernel"
- "module,ramdisk" instead of "multiboot,ramdisk" 

The rest is the same. If we sort out these small differences one way or
the other then the resulting interface should actually be fully
compatible and we could reuse the existing Dom0less (ARM) code to parse
an HyperLaunch (x86) configuration.

The top level node is not a problem. We could easily deal with both
"hypervisor" and also "chosen". Or we could pick a third different name
for both: "domains" which is the one used by System Device Tree.

I think we should rename "module-addr" to "reg" in the hyperlaunch
design document. I don't think it would have any effect on the existing
hyperlaunch (x86) code and usage because direct addresses are typically
not used on x86.

"module,kernel" and "module,ramdisk": we could either get rid of them in
favor of "multiboot,kernel" and "multiboot,ramdisk", or we could add
"module,kernel" and "module,ramdisk" as alternative aliases in the
existing dom0less (ARM) code. We already have "xen,linux-zimage" and
"xen,linux-initrd" as aliases so it is not a problem.


Also, I do think that Dom0less stakeholders would benefit from
Hyperlaunch code such as Dom0's reduction of privilege. Things like
"permissions" and "functions" of the Hyperlauch device tree interface
design document.


So, my opinion is that we should go ahead with dom0less->hyperlaunch
rename but we should also try to make the two device tree interfaces
compatible, sorting out the small differences above. That would help a
lot in terms of documentation and tooling. It would be ideal if things
like ImageBuilder worked equally well for Hyperlaunch (x86) and Dom0less
(ARM).


P.S.
Note that I only added (ARM) and (x86) for extra clarity in this
discussion, and I don't want to keep using them going forward.