[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v4 4/4] xen/arm: Prevent Dom0 to be loaded when using dom0less
Hi Luca, > On 14 Apr 2021, at 10:14, Luca Fancellu <Luca.Fancellu@xxxxxxx> wrote: > > This patch prevents the dom0 to be loaded skipping its > building and going forward to build domUs when the dom0 > kernel is not found and at least one domU is present. > > Signed-off-by: Luca Fancellu <luca.fancellu@xxxxxxx> > Reviewed-by: Julien Grall <jgrall@xxxxxxxxxx> Reviewed-by: Bertrand Marquis <bertrand.marquis@xxxxxxx> Cheers, Bertrand > --- > v3 changes: > - Rephrase documentation > --- > docs/features/dom0less.pandoc | 7 +++--- > xen/arch/arm/setup.c | 42 ++++++++++++++++++++++++++++++++--- > 2 files changed, 43 insertions(+), 6 deletions(-) > > diff --git a/docs/features/dom0less.pandoc b/docs/features/dom0less.pandoc > index d798596cdf..c9edb529e1 100644 > --- a/docs/features/dom0less.pandoc > +++ b/docs/features/dom0less.pandoc > @@ -16,9 +16,10 @@ Multiboot specification has been extended to allow for > multiple domains > to be passed to Xen. See docs/misc/arm/device-tree/booting.txt for more > information about the Multiboot specification and how to use it. > > -Currently, a control domain ("dom0") is still required, but in the > -future it will become unnecessary when all domains are created > -directly from Xen. Instead of waiting for the control domain to be fully > +Currently, a control domain ("dom0") is still required to manage the DomU > +domains, but the system can start also without dom0 if the Device Tree > +doesn't specify the dom0 kernel and it declares one or more domUs. > +Instead of waiting for the control domain (when declared) to be fully > booted and the Xen tools to become available, domains created by Xen > this way are started right away in parallel. Hence, their boot time is > typically much shorter. > diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c > index b405f58996..ecc4f0ae98 100644 > --- a/xen/arch/arm/setup.c > +++ b/xen/arch/arm/setup.c > @@ -793,6 +793,38 @@ static void __init setup_mm(void) > } > #endif > > +static bool __init is_dom0less_mode(void) > +{ > + struct bootmodules *mods = &bootinfo.modules; > + struct bootmodule *mod; > + unsigned int i; > + bool dom0found = false; > + bool domUfound = false; > + > + /* Look into the bootmodules */ > + for ( i = 0 ; i < mods->nr_mods ; i++ ) > + { > + mod = &mods->module[i]; > + /* Find if dom0 and domU kernels are present */ > + if ( mod->kind == BOOTMOD_KERNEL ) > + { > + if ( mod->domU == false ) > + { > + dom0found = true; > + break; > + } > + else > + domUfound = true; > + } > + } > + > + /* > + * If there is no dom0 kernel but at least one domU, then we are in > + * dom0less mode > + */ > + return ( !dom0found && domUfound ); > +} > + > size_t __read_mostly dcache_line_bytes; > > /* C entry point for boot CPU */ > @@ -803,7 +835,7 @@ void __init start_xen(unsigned long boot_phys_offset, > int cpus, i; > const char *cmdline; > struct bootmodule *xen_bootmodule; > - struct domain *dom0; > + struct domain *dom0 = NULL; > int rc; > > dcache_line_bytes = read_dcache_line_bytes(); > @@ -958,7 +990,10 @@ void __init start_xen(unsigned long boot_phys_offset, > enable_errata_workarounds(); > > /* Create initial domain 0. */ > - dom0 = create_dom0(); > + if ( !is_dom0less_mode() ) > + dom0 = create_dom0(); > + else > + printk(XENLOG_INFO "Xen dom0less mode detected\n"); > > heap_init_late(); > > @@ -976,7 +1011,8 @@ void __init start_xen(unsigned long boot_phys_offset, > if ( acpi_disabled ) > create_domUs(); > > - domain_unpause_by_systemcontroller(dom0); > + if ( dom0 ) > + domain_unpause_by_systemcontroller(dom0); > > /* Switch on to the dynamically allocated stack for the idle vcpu > * since the static one we're running on is about to be freed. */ > -- > 2.17.1 >
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |