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

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


  • To: "Daniel P. Smith" <dpsmith@xxxxxxxxxxxxxxxxxxxx>
  • From: Bertrand Marquis <Bertrand.Marquis@xxxxxxx>
  • Date: Tue, 31 May 2022 10:49:50 +0000
  • Accept-language: en-GB, en-US
  • Arc-authentication-results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 63.35.35.123) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com; arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com] dmarc=[1,1,header.from=arm.com])
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none
  • Arc-message-signature: i=2; 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=Nt0BiWc4Qk2mUTO+wWjDgSo14elBfR7b1c5gfQnBeyE=; b=TerzhIz934b0JxjlS14QUoX8ocZw2kM7YVdHjLS/ziut8PliHimVa2M8LE+1c7MdLtrE2mscfsMXTU9VTBpS19RZru3LAsjtP7XjkXiyefB8F0ri2cGUovSik3b29wt/QPFMqKkwPbRFYSqPg+A8DjPGMZe3lThKqm2He7Rp6WnxFlROhm2jLfyQ8JkuECy6c2Z0B8Rtlkh8GhX5/1VwF5DvCm9EhNgLjNb493/tMJ+3Ye4rB4cItljJEaYLRj43rMrCoXEEzE6jcfzI2ilsytuwMXNCKMERAfcAgNYKO6B/zP5zJ/dl+rUAnC7tw5U0Y2DTSls6Gtv06lmOs+JQAA==
  • 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=Nt0BiWc4Qk2mUTO+wWjDgSo14elBfR7b1c5gfQnBeyE=; b=CLwZm2OgBW7xoGef82yBsZoqN/rZPQPXKAk0Q6udXfY1WAqYIRccsbRjsZHkduG/BN7FKFKoooHMoF6SCXQN/H6Kk/0AvANB9W7COMMkB2prCA44iDOoOxZHOaRyUO/xh+L9tV3AdFaVU7vh15EgUFMKH5lyrIyEpTIkuvZQdcdd/XDIK1pjdWDZvAKFQO2l0WHeVsmJLJxPj70aSBCq2Ugq1+6ky/g3q8c1+DmbX6ao811hyFs7bqr0VPEspoINTMXGfepKiXmUNIb3aZTOTtbblqrW+szejE6UOYZayEjDaB5OS016eWVHwL4s0UBUoEr9/RbDSbW3rL4sl3aEZw==
  • Arc-seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass; b=BTudENzgMkGr7XzVJb1Nlr8whRx4YaLDEUp9wxcx8rAp8m9z/rFejhTybr8+SYiEVutKdSLYRk8kC05d80OPW/LQFF6JXTou2pZLSfJj2xymhd1NQqhVwCBcfhAMqpHIUW5lqSC1AWaacrd+JvWsS273X26V3iOyWVi2sD/GS9Gt8F8MTNYqDpCNh1Jw7KTytpMEfKe15Whd3ZhQuaq+8SCTOoAytnXQxvNNjLeyNDFE0n45SZ/iDJ8qZc7WTnku/XbZQxhtqOocxP6zCXUmHIObH5ktV6D01bN7RBwc4epsriXbPxtTstdPKka4mvgSVN/m1NkudHo8NkJe/G6FmA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Q4KTmD0nfI5E2ZBAL/OS6tCqqUhxyyfUcjZQJ8WJM87Duff+XHEEpACoJnZlJ3jL9Yn015/qcMfhRvG2VgTNFqTf6simQ4q+aW/6ASCQD0/01zxGf1+cHL0SjxZModG3hzx2oQGRJxoRPW8Rjjhz6C/jBvS+E4Hrt/aCrsd1WEI9AV501TSuknHHN49t6sq+w0i1b/FCyX5cSG3xfZxXS0y3SaUMUizZ9xfFrtttyu7S9v3o2a7dNF2IdLqld/bRmDTBCWGXeFJfxs4TYhGIEQQ+C7zP95aTdIe6bfvTUX+iX9K81pnlgnAeHSiNcsbrMC4NtPXz6GzVkhSnlDs2dw==
  • Authentication-results-original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
  • Cc: 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>, Jan Beulich <jbeulich@xxxxxxxx>, Julien Grall <julien@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Delivery-date: Tue, 31 May 2022 10:50:11 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Nodisclaimer: true
  • Original-authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
  • Thread-index: AQHYdHaP7qNDYyBbfkiCxkS8602Jcq04suAAgAAbZACAAAEcAA==
  • Thread-topic: [RFC PATCH 1/4] kconfig: allow configuration of maximum modules

Hi Daniel,

> On 31 May 2022, at 11:45, Daniel P. Smith <dpsmith@xxxxxxxxxxxxxxxxxxxx> 
> 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.

If this is wanted this is ok, just mention it in the commit message so that we 
know it was on purpose.

> 
>> With that fixed, for the arm part:
>> Reviewed-by: Bertrand Marquis <bertrand.marquis@xxxxxxx>
> 
> Thank you, will add it in when I respin it for submission.

Cheers
Bertrand

> 
> v/r,
> dps




 


Rackspace

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