Re: [RFC 32/38] x86/hyperlaunch: introduce concept of core domains

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

On 4/23/25 15:50, Jason Andryuk wrote:
> On 2025-04-19 18:08, Daniel P. Smith wrote:
> > When constructing domU, and specifically the event channels for their 
> > console
> > and xenstore event channels, the domid for the backing domain must be 
> > known.
> > Therefore, the control, hardware, and xenstore domains are deemed as core
> > domains, and must be constructed before any of the other domains.
> >
> > This commit introduces the build_core_domains() function that will 
> > ensure the
> > core domains are constructed first.
> >
> > Signed-off-by: Daniel P. Smith <dpsmith@xxxxxxxxxxxxxxxxxxxx>
> > ---
> >   xen/arch/x86/domain-builder/core.c     | 68 ++++++++++++++++++++++++--
> >   xen/arch/x86/include/asm/boot-domain.h |  2 +
> >   2 files changed, 66 insertions(+), 4 deletions(-)
> >
> > diff --git a/xen/arch/x86/domain-builder/core.c b/xen/arch/x86/domain- 
> > builder/core.c
> > index 901efce62a61..f693aa46d278 100644
> > --- a/xen/arch/x86/domain-builder/core.c
> > +++ b/xen/arch/x86/domain-builder/core.c
> > @@ -103,18 +103,78 @@ void __init builder_init(struct boot_info *bi)
> >       }
> >   }
> > +static int  __init build_core_domains(struct boot_info *bi)
> > +{
> > +    int count = 0;
> > +    struct boot_domain *bd;
> > +    int hw, cd, xs;
> > +
> > +    cd = first_boot_domain_index(bi, BUILD_CAPS_CONTROL);
> > +    hw = first_boot_domain_index(bi, BUILD_CAPS_HARDWARE);
> > +    xs = first_boot_domain_index(bi, BUILD_CAPS_XENSTORE);
> This order has issues if you actually have disaggregated domains.
>
> Control and Hardware depend on Xenstore for Xenstore.
>
> Control and Xenstore depend on Hardware for console support.
>
> I re-worked the xenstore allocation to run after domain creation.  I've 
> upstreamed that for dom0less (and ARM doesn't have to deal with consoles).
> So if xenstore allocation is moved later, Hardware, Xenstore, then 
> Control works.  But xenstore and console could both be handled after the 
> fact and then the construction order doesn't matter.  The backend domid 
> is needed to construct the event channel and grant entry.  With assigned 
> domids, alloc_store_evtchn()/alloc_console_evtchn() can operate on the 
> domids instead of expecting the domain to have been constructed.
Actually, there is a larger issue here and this is going to be reworked.

V/r,
dps