NULL scheduler is not enabled by default on non-debug Xen builds. This
causes the boot time cpupools test to fail on such build jobs. Fix the issue
by explicitly specifying the config options required to enable the NULL
scheduler.

Fixes: 36e3f4158778 ("automation: Add a new job for testing boot time cpupools on arm64")
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
---
Changes in v2:
- was: automation: Do not use null scheduler for boot cpupools test
- modify the commit msg/title
- explicitly enable NULL scheduler by specifying all the required options

This patch acts as a prerequisite before merging the following patch:
https://lore.kernel.org/xen-devel/20221021132238.16056-1-michal.orzel@amd.com/
(to which Henry already gave RAB), that helped to find the issue described
in the comment.

Tests shall explicitly specify the required Kconfig options for non-default
pieces of logic, thus this patch is unrelated to the discussions whether
enabling/disabling the NULL scheduler should be controlled by DEBUG or not.
---
 automation/gitlab-ci/build.yaml | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/automation/gitlab-ci/build.yaml b/automation/gitlab-ci/build.yaml
index ddc2234faf39..716ee0b1e460 100644
--- a/automation/gitlab-ci/build.yaml
+++ b/automation/gitlab-ci/build.yaml
@@ -582,6 +582,9 @@ alpine-3.12-gcc-arm64-boot-cpupools:
   variables:
     CONTAINER: alpine:3.12-arm64v8
     EXTRA_XEN_CONFIG: |
+      CONFIG_EXPERT=y
+      CONFIG_UNSUPPORTED=y
+      CONFIG_SCHED_NULL=y
       CONFIG_BOOT_TIME_CPUPOOLS=y
 
 ## Test artifacts common
-- 
2.25.1

On Mon, 24 Oct 2022, Michal Orzel wrote:
> NULL scheduler is not enabled by default on non-debug Xen builds. This
> causes the boot time cpupools test to fail on such build jobs. Fix the issue
> by explicitly specifying the config options required to enable the NULL
> scheduler.
> 
> Fixes: 36e3f4158778 ("automation: Add a new job for testing boot time cpupools on arm64")
> Signed-off-by: Michal Orzel <michal.orzel@amd.com>

Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>

I would like a release-ack by Henry on this

> ---
> Changes in v2:
> - was: automation: Do not use null scheduler for boot cpupools test
> - modify the commit msg/title
> - explicitly enable NULL scheduler by specifying all the required options
> 
> This patch acts as a prerequisite before merging the following patch:
> https://lore.kernel.org/xen-devel/20221021132238.16056-1-michal.orzel@amd.com/
> (to which Henry already gave RAB), that helped to find the issue described
> in the comment.
> 
> Tests shall explicitly specify the required Kconfig options for non-default
> pieces of logic, thus this patch is unrelated to the discussions whether
> enabling/disabling the NULL scheduler should be controlled by DEBUG or not.
> ---
>  automation/gitlab-ci/build.yaml | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/automation/gitlab-ci/build.yaml b/automation/gitlab-ci/build.yaml
> index ddc2234faf39..716ee0b1e460 100644
> --- a/automation/gitlab-ci/build.yaml
> +++ b/automation/gitlab-ci/build.yaml
> @@ -582,6 +582,9 @@ alpine-3.12-gcc-arm64-boot-cpupools:
>    variables:
>      CONTAINER: alpine:3.12-arm64v8
>      EXTRA_XEN_CONFIG: |
> +      CONFIG_EXPERT=y
> +      CONFIG_UNSUPPORTED=y
> +      CONFIG_SCHED_NULL=y
>        CONFIG_BOOT_TIME_CPUPOOLS=y
>  
>  ## Test artifacts common
> -- 
> 2.25.1
>

Hi Stefano and Michal,

> -----Original Message-----
> From: Stefano Stabellini <sstabellini@kernel.org>
> Subject: Re: [for-4.17, PATCH v2] automation: Explicitly enable NULL
> scheduler for boot-cpupools test
> 
> On Mon, 24 Oct 2022, Michal Orzel wrote:
> > NULL scheduler is not enabled by default on non-debug Xen builds. This
> > causes the boot time cpupools test to fail on such build jobs. Fix the issue
> > by explicitly specifying the config options required to enable the NULL
> > scheduler.
> >
> > Fixes: 36e3f4158778 ("automation: Add a new job for testing boot time
> cpupools on arm64")
> > Signed-off-by: Michal Orzel <michal.orzel@amd.com>
> 
> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
> 
> I would like a release-ack by Henry on this

Release-acked-by: Henry Wang <Henry.Wang@arm.com>

Kind regards,
Henry