Re: [PATCH v2 1/2] docs: update hyperlaunch device tree

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Tue, 8 Aug 2023, Daniel P. Smith wrote:
> On 8/3/23 19:38, Stefano Stabellini wrote:
> > On Thu, 3 Aug 2023, Daniel P. Smith wrote:
> > > > Also, what is the plan for the existing dom0less dt properties?
> > > > Will they need to be moved to new /hypervisor node or we will have to
> > > > parse
> > > > both /chosen and /hypervisor nodes?
> > > 
> > > In the proposal I sent to xen-devel in response to Luca's RFC for
> > > rebranding
> > > dom0less features under hyperlaunch, that is the purpose of this commit.
> > > Get
> > > this document up to date with what was done in v1 along with what we are
> > > planning/working on for hyperlaunch. One could think of this as
> > > effectively
> > > the API to the capabilities hyperlaunch will provide. Not just how to
> > > construct a domain, but what kinds of domains can be constructed by
> > > hyperlaunch. Step one of the proposal is to publish a patch upon which we
> > > all
> > > can iterate over and get to an agreement on a suitable interface for all.
> > > The
> > > next step would be the introduction of hyperlaunch dom0less compatibility
> > > mode, that would see the moving of the parsing logic for the existing
> > > dom0less
> > > nodes under /xen/common/domain-builder. It would continue to exist there
> > > even
> > > after hyperlaunch proper is merged and can remain there for backward
> > > compatibility until there is a decision to retire the compatibility
> > > interface.
> > 
> > I like this plan. The two interfaces are so similar that it is basically
> > one interface with a couple of tiny differences.
> > 
> > So I expect we would move the existing dom0less parsing code to common/,
> > add a couple of extensions (such as parsing /hypervisor in addition to
> > /chosen) and use it as it.
> 
> Do you mean /chosen/hypervisor?

I meant /hypervisor as in "the node under which the hyperlaunch
configuration is presented". If HyperLaunch uses /chosen/hypervisor,
then that's what I meant :-)


> > Later on, after a few years of using /hypervisor instead of /chosen, if
> > nobody is using /chosen anymore, we could retire /chosen completely. But
> > this is just one DT node/property that gets retired (there are a couple
> > of others). I don't imagine we'll have a full new implementation of the
> > DT parsing logic that supersedes the existing implementation of it
> > (especially considering the difficulty of maintaining 2 different parsing
> > logics in the hypervisor for similar interfaces).
> 
> +1
> 
> > Same thing for the DT interface documentation. I don't think we need two
> > DT interface docs? We could start with the existing dom0less interface
> > (docs/misc/arm/device-tree/booting.txt), and move it somewhere common
> > like docs/misc/device-tree.
> 
> So in the plan that I sent, patch series 3 was were I was going to consolidate
> docs/design/launch/hyperlaunch-devicetree.rst and
> docs/misc/arm/device-tree/booting.txt into a single document under
> docs/features/hyperlaunch/device-tree.rst along with moving
> docs/features/dom0less.pandoc to
> docs/features/hyperlaunch/dom0less-compatibility-mode.pandoc. The thinking
> here was to get all the feature documentation together in a single place, but
> I would be open to putting the suggested consolidated device-tree.rst
> mentioned above into docs/misc/device-tree/hyperlaunch.rst if that is
> preferred.

Yes I think we should have a single consolidated document, because it is
not a good idea to support very similar but subtly different interfaces
on ARM/x86. docs/misc/device-tree/hyperlaunch.rst should work fine.

And I think we should try to minimize differences and have a single
common parsing code.

Any role definition introduced by hyperlaunch originally for x86 would
undoubtedly be useful on ARM. Conversely, all the existing ARM dom0less
tools (ImageBuilder) might be useful on x86 too. RISC-V might use it too
in the near future.


> > Then add any changes or extensions required by other architecture, such
> > as x86 and RISC-V.
> > 
> > For sure for x86 we need "module-index". I don't know if anything else
> > is must-have to get it to work on x86 but if there is, we should add
> > those too.
> 
> Hmm good point, since in the suggested patch series 3 from the plan, this
> probably should get cropped down to what we actually have implemented for x86
> hyperlaunch and then get expanded as it becomes feature complete.

Yes exactly. So I think the best way to move forward is something along
these lines:
a) work on a single arch-neutral hyperlaunch/dom0less DT interface
   document for ARM/x86/RISC-V
b) in parallel, move dom0less parsing code to common (AMD might be able
   to work on this, to be confirmed)
c) add x86 features as needed to the code and to the interface doc,
   "module-index" would probably be among the first ones
d) as we add more features, we expand the hyperlaunch/dom0less DT
   interface document


I think a) only really needs the smallest amount of changes to make it
work on non-ARM architectures