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? Jan
