[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: Roger Pau Monné <roger.pau@xxxxxxxxxx>, "Daniel P. Smith" <dpsmith@xxxxxxxxxxxxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Tue, 31 May 2022 15:54:03 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=nMOZ9lOX2mNrBi6/JYl8p98MUBZnHa260B069jDXq6c=; b=d6iHhS88LRaEAb7b/L0K6q1rU5UA90R127M4l0MFRxYoQvXqTtt5HBCAryqWJBcnotU6EiNt7zirEMAgtEOw4JZjhuhS4ESJ7/ucdGmyYey/GPaBudmYWM6P8swYQb3+A12kvTKFkWIGqMD494T7DHTl+Ou46PDpLAt4chS6bQYBpk4xbIred7H3KLkClnXQflto7Nk8+4FYLKltT5d8G9+/AWe0Kv9CMGOwNSuXTpQsD7fYSFtcjpGvFgX2q5r/2WllSkXnNKnw3R5IVqCJkn6iMjDFcJTYkNaLMZpgJWdruCpRh9vp2k+pi3E5cnKmik9S52XXmbVpgjTciBNZcw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JuWKW6+pzoffZIN0+31ni16SLulr/sQWor5Feo9FerRzxKNhxvqqxhq54FzQbjk/3EezL3BGagnkqvrETHwFHI8yqbJ66LtAF231RWJLGfTd61xBbP46Av13rLkinSuC2u6mDynvIJ1ZcW9dSYqC0SbbbxjnvhdQR3hIgGCvYI1bldCksQPn2l+dQBOhE5Yg7z2hA+PBvX7+CS4DuW+xXDeB3wyHGW8/u/HgWhzfzw9BXh/FyAbU1g7e0QVIYDn2SXGnNhWJKAa1FFyvsEFiKjMg0vLycMATVHflK499Aicw/iP4L62Tb+u1f8uyxjjYhwl97ypwBfVN4KdgWu6Ldw==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Bertrand Marquis <Bertrand.Marquis@xxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Wei Liu <wl@xxxxxxx>, "scott.davis@xxxxxxxxxx" <scott.davis@xxxxxxxxxx>, "christopher.clark@xxxxxxxxxx" <christopher.clark@xxxxxxxxxx>, "sstabellini@xxxxxxxxxx" <sstabellini@xxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>
  • Delivery-date: Tue, 31 May 2022 13:54:19 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 31.05.2022 15:52, Roger Pau Monné wrote:
> On Tue, May 31, 2022 at 06:45:52AM -0400, Daniel P. Smith wrote:
>> On 5/31/22 05:07, Bertrand Marquis wrote:
>>> Hi Daniel,
>>
>> Greetings Bertrand.
>>
>>>> On 31 May 2022, at 03:41, Daniel P. Smith <dpsmith@xxxxxxxxxxxxxxxxxxxx> 
>>>> wrote:
>>>>
>>>> For x86 the number of allowable multiboot modules varies between the 
>>>> different
>>>> entry points, non-efi boot, pvh boot, and efi boot. In the case of both 
>>>> Arm and
>>>> x86 this value is fixed to values based on generalized assumptions. With
>>>> hyperlaunch for x86 and dom0less on Arm, use of static sizes results in 
>>>> large
>>>> allocations compiled into the hypervisor that will go unused by many use 
>>>> cases.
>>>>
>>>> This commit introduces a Kconfig variable that is set with sane defaults 
>>>> based
>>>> on configuration selection. This variable is in turned used as the array 
>>>> size
>>>> for the cases where a static allocated array of boot modules is declared.
>>>>
>>>> Signed-off-by: Daniel P. Smith <dpsmith@xxxxxxxxxxxxxxxxxxxx>
>>>> ---
>>>> xen/arch/Kconfig                  | 12 ++++++++++++
>>>> xen/arch/arm/include/asm/setup.h  |  5 +++--
>>>> xen/arch/x86/efi/efi-boot.h       |  2 +-
>>>> xen/arch/x86/guest/xen/pvh-boot.c |  2 +-
>>>> xen/arch/x86/setup.c              |  4 ++--
>>>> 5 files changed, 19 insertions(+), 6 deletions(-)
>>>>
>>>> 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
>>>> +  default "8" if X86
>>>> +  default "32" if ARM
>>>> +  help
>>>> +    Controls the build-time size of various arrays allocated for
>>>> +    parsing the boot modules passed by a loader when starting Xen.
>>>> +
>>>> +    This is of particular interest when using Xen's hypervisor domain
>>>> +    capabilities such as dom0less.
>>>> diff --git a/xen/arch/arm/include/asm/setup.h 
>>>> b/xen/arch/arm/include/asm/setup.h
>>>> index 2bb01ecfa8..312a3e4209 100644
>>>> --- a/xen/arch/arm/include/asm/setup.h
>>>> +++ b/xen/arch/arm/include/asm/setup.h
>>>> @@ -10,7 +10,8 @@
>>>>
>>>> #define NR_MEM_BANKS 256
>>>>
>>>> -#define MAX_MODULES 32 /* Current maximum useful modules */
>>>> +/* Current maximum useful modules */
>>>> +#define MAX_MODULES CONFIG_NR_BOOTMODS
>>>>
>>>> typedef enum {
>>>>     BOOTMOD_XEN,
>>>> @@ -38,7 +39,7 @@ struct meminfo {
>>>>  * The domU flag is set for kernels and ramdisks of "xen,domain" nodes.
>>>>  * The purpose of the domU flag is to avoid getting confused in
>>>>  * kernel_probe, where we try to guess which is the dom0 kernel and
>>>> - * initrd to be compatible with all versions of the multiboot spec. 
>>>> + * initrd to be compatible with all versions of the multiboot spec.
>>>
>>> This seems to be a spurious change.
>>
>> I have been trying to clean up trailing white space when I see it
>> nearby. I can drop this one if that is desired.
> 
> IMO it's best if such white space removal is only done when already
> modifying the line, or else it makes it harder to track changes when
> using `git blame` for example (not likely in this case since it's a
> multi line comment).

+1

Jan




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.