On 19.07.2022 19:02, Daniel P. Smith wrote:
> On 7/19/22 05:32, Jan Beulich wrote:
>> On 06.07.2022 23:04, Daniel P. Smith wrote:
>>> --- a/xen/arch/x86/efi/efi-boot.h
>>> +++ b/xen/arch/x86/efi/efi-boot.h
>>> @@ -18,7 +18,7 @@ static multiboot_info_t __initdata mbi = {
>>> * The array size needs to be one larger than the number of modules we
>>> * support - see __start_xen().
>>> */
>>> -static module_t __initdata mb_modules[5];
>>> +static module_t __initdata mb_modules[CONFIG_NR_BOOTMODS + 1];
>>
>> If the build admin selected 1, I'm pretty sure about nothing would work.
>> I think you want max(5, CONFIG_NR_BOOTMODS) or
>> max(4, CONFIG_NR_BOOTMODS) + 1 here and ...
>
> Actually, I reasoned this out and 1 is in fact a valid value. It would
> mean Xen + Dom0 Linux kernel with embedded initramfs with no externally
> loaded XSM policy and no boot time microcode patching. This is a working
> configuration, but open to debate if it is a desirable configuration.
> The question is whether it is desired to block someone from building
> such a configuration, or any number between 1 and 4. If the answer is
> yes, then why not just set the lower bound of the range in the Kconfig
> file instead of having to maintain a hard-coded lower bound in a max
> marco across multiple locations?
While I'd be fine with the lower bounds being raised, I wouldn't be very
happy with seeing those lower bounds becoming arch-specific.
Jan
