Re: [RFC PATCH 1/4] kconfig: allow configuration of maximum modules

[Julien Grall <julien@xxxxxxx>]

Hi,

On 02/06/2022 09:49, Jan Beulich wrote:
> On 01.06.2022 19:35, Julien Grall wrote:
> > On 31/05/2022 11:53, Daniel P. Smith wrote:
> > > On 5/31/22 05:25, Julien Grall wrote:
> > > > Hi,
> > > >
> > > > On 31/05/2022 03:41, Daniel P. Smith wrote:
> > > > > diff --git a/xen/arch/Kconfig b/xen/arch/Kconfig
> > > > > index f16eb0df43..57b14e22c9 100644
> > > > > --- a/xen/arch/Kconfig
> > > > > +++ b/xen/arch/Kconfig
> > > > > @@ -17,3 +17,15 @@ config NR_CPUS
> > > > >           For CPU cores which support Simultaneous Multi-Threading or
> > > > > similar
> > > > >           technologies, this the number of logical threads which Xen will
> > > > >           support.
> > > > > +
> > > > > +config NR_BOOTMODS
> > > > > +    int "Maximum number of boot modules that a loader can pass"
> > > > > +    range 1 64
> > > > OOI, any reason to limit the size?
> > > I modelled this entirely after NR_CPUS, which applied a limit
> > The limit for NR_CPUS makes sense because there are scalability issues
> > after that (although 4095 seems quite high) and/or the HW impose a limit.
> The 4095 is actually a software limit (due to how spinlocks are
> implemented).
>
> > > , and it
> > > seemed reasonable to me at the time. I choose 64 since it was double
> > > currently what Arm had set for MAX_MODULES. As such, I have no hard
> > > reason for there to be a limit. It can easily be removed or adjusted to
> > > whatever the reviewers feel would be appropriate.
> > Ok. In which case I would drop the limit beause it also prevent a users
> > to create more 64 dom0less domUs (actually a bit less because some
> > modules are used by Xen). I don't think there are a strong reason to
> > prevent that, right?
> At least as per the kconfig language doc the upper bound is not
> optional, so if a range is specified (which I think it should be,
> to enforce the lower limit of 1) and upper bound is needed. To
> address your concern with dom0less - 32768 maybe?
I am fine with that.

Cheers,

--
Julien Grall