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

["Daniel P. Smith" <dpsmith@xxxxxxxxxxxxxxxxxxxx>]

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?

> 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.
> 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.
v/r,
dps