Re: [RFC PATCH] docs/designs: domB design document

[Christopher Clark <christopher.w.clark@xxxxxxxxx>]

On Thu, May 7, 2020 at 1:15 AM Jan Beulich <jbeulich@xxxxxxxx> wrote:
>
> On 06.05.2020 05:23, Christopher Clark wrote:
> > +It is with this understanding as presented that the DomB project used as 
> > the
> > +basis for the development of its multiple domain boot capability for Xen. 
> > Within
> > +the remainder of this document is a detailed explanation of the multiple 
> > domain
> > +boot, the objectives it strives to achieve, the structure behind the 
> > approach,
> > +the sequence events in a boot, a contrasting with ARM’s dom0less, and 
> > closing
> > +with some exemplar implementations.
>
> May I ask that along with dom0less you also explain the (non-)relationship
> to the late-Dom0 model we've been having for a number of years? Some
> aspects of what the boot domain does look, to me, quite similar.

I haven't seen the term 'late-Dom0' used before, so am inferring that
you might mean the 'late hardware domain' feature of Xen, in which
case: yes, thanks - we will add a contrast section on how DomB relates
to that. At this (early) point, I think that we should be able to
retire/replace Xen's late hardware domain implementation in favour of
DomB, if that direction is acceptable to the community; so we will
look into how it relates.

> Apart from this one immediate detail I'm curious about (and that I also
> don't know/recall how it gets handled with dom0less): Death of Dom0 in a
> traditional setup is a signal to Xen to reboot the host. With any of the
> boot time created domains not functioning anymore, the intended purpose
> of the host may no longer be fulfilled. But of course there may be a
> subset of "optional" domains. As a result - are there any intentions
> towards identifying under what conditions it may be better to reboot the
> host than wait for human interaction?

Excellent point; we have given it some limited consideration -- eg.
something should be able to be expressed in the per-domain metadata
supplied in the Launch Control Module, to set state that is held in
Xen's domain struct for acting upon on domain exit -- but it is not
included in the design document yet and indeed it ought to be.

Thanks for the review.

Christopher