[PATCH v3 0/6] Boot time cpupools

[PATCH v3 0/6] Boot time cpupools

[Luca Fancellu]

This serie introduces a feature for Xen to create cpu pools at boot time, the
feature is enabled using a configurable that is disabled by default.
The boot time cpupool feature relies on the device tree to describe the cpu
pools.
Another feature is introduced by the serie, the possibility to assign a
dom0less guest to a cpupool at boot time.

Here follows an example, Xen is built with CONFIG_BOOT_TIME_CPUPOOLS=y.

From the DT:

  [...]

  a72_0: cpu@0 {
    compatible = "arm,cortex-a72";
    reg = <0x0 0x0>;
    device_type = "cpu";
    [...]
  };

  a72_1: cpu@1 {
    compatible = "arm,cortex-a72";
    reg = <0x0 0x1>;
    device_type = "cpu";
    [...]
  };

  a53_0: cpu@100 {
    compatible = "arm,cortex-a53";
    reg = <0x0 0x100>;
    device_type = "cpu";
    [...]
  };

  a53_1: cpu@101 {
    compatible = "arm,cortex-a53";
    reg = <0x0 0x101>;
    device_type = "cpu";
    [...]
  };

  a53_2: cpu@102 {
    compatible = "arm,cortex-a53";
    reg = <0x0 0x102>;
    device_type = "cpu";
    [...]
  };

  a53_3: cpu@103 {
    compatible = "arm,cortex-a53";
    reg = <0x0 0x103>;
    device_type = "cpu";
    [...]
  };

  chosen {
    #size-cells = <0x1>;
    #address-cells = <0x1>;
    xen,dom0-bootargs = "...";
    xen,xen-bootargs = "...";

    cpupool0 {
      compatible = "xen,cpupool";
      cpupool-cpus = <&a72_0 &a72_1>;
      cpupool-sched = "credit2";
    };

    cp1: cpupool1 {
      compatible = "xen,cpupool";
      cpupool-cpus = <&a53_0 &a53_1 &a53_2 &a53_3>;
    };

    module@0 {
      reg = <0x80080000 0x1300000>;
      compatible = "multiboot,module";
    };

    domU1 {
      #size-cells = <0x1>;
      #address-cells = <0x1>;
      compatible = "xen,domain";
      cpus = <1>;
      memory = <0 0xC0000>;
      vpl011;
      domain-cpupool = <&cp1>;

      module@92000000 {
        compatible = "multiboot,kernel", "multiboot,module";
        reg = <0x92000000 0x1ffffff>;
        bootargs = "...";
      };
    };
  };

  [...]

The example DT is instructing Xen to have two cpu pools, the one with id 0
having two phisical cpus and the one with id 1 having 4 phisical cpu, the
second cpu pool uses the null scheduler and from the /chosen node we can see
that a dom0less guest will be started on that cpu pool.

In this particular case Xen must boot with different type of cpus, so the
boot argument hmp_unsafe must be enabled.


Luca Fancellu (6):
  tools/cpupools: Give a name to unnamed cpupools
  xen/sched: create public function for cpupools creation
  xen/sched: retrieve scheduler id by name
  xen/cpupool: Create different cpupools at boot time
  arm/dom0less: assign dom0less guests to cpupools
  xen/cpupool: Allow cpupool0 to use different scheduler

 docs/misc/arm/device-tree/booting.txt  |   5 +
 docs/misc/arm/device-tree/cpupools.txt | 135 ++++++++++++++++
 tools/helpers/xen-init-dom0.c          |  35 ++++-
 tools/libs/light/libxl_utils.c         |   3 +-
 xen/arch/arm/domain_build.c            |  14 +-
 xen/arch/arm/include/asm/smp.h         |   3 +
 xen/common/Kconfig                     |   7 +
 xen/common/Makefile                    |   1 +
 xen/common/boot_cpupools.c             | 205 +++++++++++++++++++++++++
 xen/common/domain.c                    |   2 +-
 xen/common/sched/core.c                |  40 +++--
 xen/common/sched/cpupool.c             |  32 +++-
 xen/include/public/domctl.h            |   4 +-
 xen/include/xen/sched.h                |  58 +++++++
 14 files changed, 516 insertions(+), 28 deletions(-)
 create mode 100644 docs/misc/arm/device-tree/cpupools.txt
 create mode 100644 xen/common/boot_cpupools.c

-- 
2.17.1

[PATCH v3 1/6] tools/cpupools: Give a name to unnamed cpupools

[Luca Fancellu]

With the introduction of boot time cpupools, Xen can create many
different cpupools at boot time other than cpupool with id 0.

Since these newly created cpupools can't have an
entry in Xenstore, create the entry using xen-init-dom0
helper with the usual convention: Pool-<cpupool id>.

Given the change, remove the check for poolid == 0 from
libxl_cpupoolid_to_name(...).

Signed-off-by: Luca Fancellu <luca.fancellu@arm.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
---
Changes in v3:
- no changes, add R-by
Changes in v2:
 - Remove unused variable, moved xc_cpupool_infofree
   ahead to simplify the code, use asprintf (Juergen)
---
 tools/helpers/xen-init-dom0.c  | 35 +++++++++++++++++++++++++++++++++-
 tools/libs/light/libxl_utils.c |  3 +--
 2 files changed, 35 insertions(+), 3 deletions(-)

diff --git a/tools/helpers/xen-init-dom0.c b/tools/helpers/xen-init-dom0.c
index c99224a4b607..84286617790f 100644
--- a/tools/helpers/xen-init-dom0.c
+++ b/tools/helpers/xen-init-dom0.c
@@ -43,7 +43,9 @@ int main(int argc, char **argv)
     int rc;
     struct xs_handle *xsh = NULL;
     xc_interface *xch = NULL;
-    char *domname_string = NULL, *domid_string = NULL;
+    char *domname_string = NULL, *domid_string = NULL, *pool_path, *pool_name;
+    xc_cpupoolinfo_t *xcinfo;
+    unsigned int pool_id = 0;
     libxl_uuid uuid;
 
     /* Accept 0 or 1 argument */
@@ -114,6 +116,37 @@ int main(int argc, char **argv)
         goto out;
     }
 
+    /* Create an entry in xenstore for each cpupool on the system */
+    do {
+        xcinfo = xc_cpupool_getinfo(xch, pool_id);
+        if (xcinfo != NULL) {
+            if (xcinfo->cpupool_id != pool_id)
+                pool_id = xcinfo->cpupool_id;
+            xc_cpupool_infofree(xch, xcinfo);
+            if (asprintf(&pool_path, "/local/pool/%d/name", pool_id) <= 0) {
+                fprintf(stderr, "cannot allocate memory for pool path\n");
+                rc = 1;
+                goto out;
+            }
+            if (asprintf(&pool_name, "Pool-%d", pool_id) <= 0) {
+                fprintf(stderr, "cannot allocate memory for pool name\n");
+                rc = 1;
+                goto out_err;
+            }
+            pool_id++;
+            if (!xs_write(xsh, XBT_NULL, pool_path, pool_name,
+                          strlen(pool_name))) {
+                fprintf(stderr, "cannot set pool name\n");
+                rc = 1;
+            }
+            free(pool_name);
+out_err:
+            free(pool_path);
+            if ( rc )
+                goto out;
+        }
+    } while(xcinfo != NULL);
+
     printf("Done setting up Dom0\n");
 
 out:
diff --git a/tools/libs/light/libxl_utils.c b/tools/libs/light/libxl_utils.c
index b91c2cafa223..81780da3ff40 100644
--- a/tools/libs/light/libxl_utils.c
+++ b/tools/libs/light/libxl_utils.c
@@ -151,8 +151,7 @@ char *libxl_cpupoolid_to_name(libxl_ctx *ctx, uint32_t poolid)
 
     snprintf(path, sizeof(path), "/local/pool/%d/name", poolid);
     s = xs_read(ctx->xsh, XBT_NULL, path, &len);
-    if (!s && (poolid == 0))
-        return strdup("Pool-0");
+
     return s;
 }
 
-- 
2.17.1

[PATCH v3 2/6] xen/sched: create public function for cpupools creation

[Luca Fancellu]

Create new public function to create cpupools, can take as parameter
the scheduler id or a negative value that means the default Xen
scheduler will be used.

Signed-off-by: Luca Fancellu <luca.fancellu@arm.com>
---
Changes in v3:
- Fixed comment (Andrew)
Changes in v2:
- cpupool_create_pool doesn't check anymore for pool id uniqueness
  before calling cpupool_create. Modified commit message accordingly
---
 xen/common/sched/cpupool.c | 15 +++++++++++++++
 xen/include/xen/sched.h    | 16 ++++++++++++++++
 2 files changed, 31 insertions(+)

diff --git a/xen/common/sched/cpupool.c b/xen/common/sched/cpupool.c
index a6da4970506a..89a891af7076 100644
--- a/xen/common/sched/cpupool.c
+++ b/xen/common/sched/cpupool.c
@@ -1219,6 +1219,21 @@ static void cpupool_hypfs_init(void)
 
 #endif /* CONFIG_HYPFS */
 
+struct cpupool *__init cpupool_create_pool(unsigned int pool_id, int sched_id)
+{
+    struct cpupool *pool;
+
+    if ( sched_id < 0 )
+        sched_id = scheduler_get_default()->sched_id;
+
+    pool = cpupool_create(pool_id, sched_id);
+
+    BUG_ON(IS_ERR(pool));
+    cpupool_put(pool);
+
+    return pool;
+}
+
 static int __init cf_check cpupool_init(void)
 {
     unsigned int cpu;
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 10ea969c7af9..415b939ba8ae 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -1145,6 +1145,22 @@ int cpupool_move_domain(struct domain *d, struct cpupool *c);
 int cpupool_do_sysctl(struct xen_sysctl_cpupool_op *op);
 unsigned int cpupool_get_id(const struct domain *d);
 const cpumask_t *cpupool_valid_cpus(const struct cpupool *pool);
+
+/*
+ * cpupool_create_pool - Creates a cpupool
+ * @pool_id: id of the pool to be created
+ * @sched_id: id of the scheduler to be used for the pool
+ *
+ * Creates a cpupool with pool_id id.
+ * The sched_id parameter identifies the scheduler to be used, if it is
+ * negative, the default scheduler of Xen will be used.
+ *
+ * returns:
+ *     pointer to the struct cpupool just created, or Xen will panic in case of
+ *     error
+ */
+struct cpupool *cpupool_create_pool(unsigned int pool_id, int sched_id);
+
 extern void cf_check dump_runq(unsigned char key);
 
 void arch_do_physinfo(struct xen_sysctl_physinfo *pi);
-- 
2.17.1

[PATCH v3 3/6] xen/sched: retrieve scheduler id by name

[Luca Fancellu]

Add a static function to retrieve the scheduler pointer using the
scheduler name.

Add a public function to retrieve the scheduler id by the scheduler
name that makes use of the new static function.

Take the occasion to replace open coded scheduler search with the
new static function in scheduler_init.

Signed-off-by: Luca Fancellu <luca.fancellu@arm.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
---
Changes in v3:
- add R-by
Changes in v2:
- replace open coded scheduler search in scheduler_init (Juergen)
---
 xen/common/sched/core.c | 40 ++++++++++++++++++++++++++--------------
 xen/include/xen/sched.h | 11 +++++++++++
 2 files changed, 37 insertions(+), 14 deletions(-)

diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c
index 19ab67818106..48ee01420fb8 100644
--- a/xen/common/sched/core.c
+++ b/xen/common/sched/core.c
@@ -2947,10 +2947,30 @@ void scheduler_enable(void)
     scheduler_active = true;
 }
 
+static inline
+const struct scheduler *__init sched_get_by_name(const char *sched_name)
+{
+    unsigned int i;
+
+    for ( i = 0; i < NUM_SCHEDULERS; i++ )
+        if ( schedulers[i] && !strcmp(schedulers[i]->opt_name, sched_name) )
+            return schedulers[i];
+
+    return NULL;
+}
+
+int __init sched_get_id_by_name(const char *sched_name)
+{
+    const struct scheduler *scheduler = sched_get_by_name(sched_name);
+
+    return scheduler ? scheduler->sched_id : -1;
+}
+
 /* Initialise the data structures. */
 void __init scheduler_init(void)
 {
     struct domain *idle_domain;
+    const struct scheduler *scheduler;
     int i;
 
     scheduler_enable();
@@ -2981,25 +3001,17 @@ void __init scheduler_init(void)
                    schedulers[i]->opt_name);
             schedulers[i] = NULL;
         }
-
-        if ( schedulers[i] && !ops.name &&
-             !strcmp(schedulers[i]->opt_name, opt_sched) )
-            ops = *schedulers[i];
     }
 
-    if ( !ops.name )
+    scheduler = sched_get_by_name(opt_sched);
+    if ( !scheduler )
     {
         printk("Could not find scheduler: %s\n", opt_sched);
-        for ( i = 0; i < NUM_SCHEDULERS; i++ )
-            if ( schedulers[i] &&
-                 !strcmp(schedulers[i]->opt_name, CONFIG_SCHED_DEFAULT) )
-            {
-                ops = *schedulers[i];
-                break;
-            }
-        BUG_ON(!ops.name);
-        printk("Using '%s' (%s)\n", ops.name, ops.opt_name);
+        scheduler = sched_get_by_name(CONFIG_SCHED_DEFAULT);
+        BUG_ON(!scheduler);
+        printk("Using '%s' (%s)\n", scheduler->name, scheduler->opt_name);
     }
+    ops = *scheduler;
 
     if ( cpu_schedule_up(0) )
         BUG();
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 415b939ba8ae..4050e22544f9 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -756,6 +756,17 @@ void sched_destroy_domain(struct domain *d);
 long sched_adjust(struct domain *, struct xen_domctl_scheduler_op *);
 long sched_adjust_global(struct xen_sysctl_scheduler_op *);
 int  sched_id(void);
+
+/*
+ * sched_get_id_by_name - retrieves a scheduler id given a scheduler name
+ * @sched_name: scheduler name as a string
+ *
+ * returns:
+ *     positive value being the scheduler id, on success
+ *     negative value if the scheduler name is not found.
+ */
+int sched_get_id_by_name(const char *sched_name);
+
 void vcpu_wake(struct vcpu *v);
 long vcpu_yield(void);
 void vcpu_sleep_nosync(struct vcpu *v);
-- 
2.17.1

[PATCH v3 4/6] xen/cpupool: Create different cpupools at boot time

[Luca Fancellu]

Introduce a way to create different cpupools at boot time, this is
particularly useful on ARM big.LITTLE system where there might be the
need to have different cpupools for each type of core, but also
systems using NUMA can have different cpu pools for each node.

The feature on arm relies on a specification of the cpupools from the
device tree to build pools and assign cpus to them.

Documentation is created to explain the feature.

Signed-off-by: Luca Fancellu <luca.fancellu@arm.com>
---
Changes in v3:
- Add newline to cpupools.txt and removed "default n" from Kconfig (Jan)
- Fixed comment, moved defines, used global cpu_online_map, use
  HAS_DEVICE_TREE instead of ARM and place arch specific code in header
  (Juergen)
- Fix brakets, x86 code only panic, get rid of scheduler dt node, don't
  save pool pointer and look for it from the pool list (Stefano)
- Changed data structures to allow modification to the code.
Changes in v2:
- Move feature to common code (Juergen)
- Try to decouple dtb parse and cpupool creation to allow
  more way to specify cpupools (for example command line)
- Created standalone dt node for the scheduler so it can
  be used in future work to set scheduler specific
  parameters
- Use only auto generated ids for cpupools
---
 docs/misc/arm/device-tree/cpupools.txt | 135 +++++++++++++++++++
 xen/arch/arm/include/asm/smp.h         |   3 +
 xen/common/Kconfig                     |   7 +
 xen/common/Makefile                    |   1 +
 xen/common/boot_cpupools.c             | 178 +++++++++++++++++++++++++
 xen/common/sched/cpupool.c             |   9 +-
 xen/include/xen/sched.h                |  19 +++
 7 files changed, 351 insertions(+), 1 deletion(-)
 create mode 100644 docs/misc/arm/device-tree/cpupools.txt
 create mode 100644 xen/common/boot_cpupools.c

diff --git a/docs/misc/arm/device-tree/cpupools.txt b/docs/misc/arm/device-tree/cpupools.txt
new file mode 100644
index 000000000000..6d7463736b48
--- /dev/null
+++ b/docs/misc/arm/device-tree/cpupools.txt
@@ -0,0 +1,135 @@
+Boot time cpupools
+==================
+
+When BOOT_TIME_CPUPOOLS is enabled in the Xen configuration, it is possible to
+create cpupools during boot phase by specifying them in the device tree.
+
+Cpupools specification nodes shall be direct childs of /chosen node.
+Each cpupool node contains the following properties:
+
+- compatible (mandatory)
+
+    Must always include the compatiblity string: "xen,cpupool".
+
+- cpupool-cpus (mandatory)
+
+    Must be a list of device tree phandle to nodes describing cpus (e.g. having
+    device_type = "cpu"), it can't be empty.
+
+- cpupool-sched (optional)
+
+    Must be a string having the name of a Xen scheduler, it has no effect when
+    used in conjunction of a cpupool-id equal to zero, in that case the
+    default Xen scheduler is selected (sched=<...> boot argument).
+    Check the sched=<...> boot argument for allowed values.
+
+
+Constraints
+===========
+
+If no cpupools are specified, all cpus will be assigned to one cpupool
+implicitly created (Pool-0).
+
+If cpupools node are specified, but not every cpu brought up by Xen is assigned,
+all the not assigned cpu will be assigned to an additional cpupool.
+
+If a cpu is assigned to a cpupool, but it's not brought up correctly, Xen will
+stop.
+
+
+Examples
+========
+
+A system having two types of core, the following device tree specification will
+instruct Xen to have two cpupools:
+
+- The cpupool with id 0 will have 4 cpus assigned.
+- The cpupool with id 1 will have 2 cpus assigned.
+
+The following example can work only if hmp-unsafe=1 is passed to Xen boot
+arguments, otherwise not all cores will be brought up by Xen and the cpupool
+creation process will stop Xen.
+
+
+a72_1: cpu@0 {
+        compatible = "arm,cortex-a72";
+        reg = <0x0 0x0>;
+        device_type = "cpu";
+        [...]
+};
+
+a72_2: cpu@1 {
+        compatible = "arm,cortex-a72";
+        reg = <0x0 0x1>;
+        device_type = "cpu";
+        [...]
+};
+
+a53_1: cpu@100 {
+        compatible = "arm,cortex-a53";
+        reg = <0x0 0x100>;
+        device_type = "cpu";
+        [...]
+};
+
+a53_2: cpu@101 {
+        compatible = "arm,cortex-a53";
+        reg = <0x0 0x101>;
+        device_type = "cpu";
+        [...]
+};
+
+a53_3: cpu@102 {
+        compatible = "arm,cortex-a53";
+        reg = <0x0 0x102>;
+        device_type = "cpu";
+        [...]
+};
+
+a53_4: cpu@103 {
+        compatible = "arm,cortex-a53";
+        reg = <0x0 0x103>;
+        device_type = "cpu";
+        [...]
+};
+
+chosen {
+
+    cpupool_a {
+        compatible = "xen,cpupool";
+        cpupool-cpus = <&a53_1 &a53_2 &a53_3 &a53_4>;
+    };
+    cpupool_b {
+        compatible = "xen,cpupool";
+        cpupool-cpus = <&a72_1 &a72_2>;
+        cpupool-sched = "credit2";
+    };
+
+    [...]
+
+};
+
+
+A system having the cpupools specification below will instruct Xen to have three
+cpupools:
+
+- The cpupool Pool-0 will have 2 cpus assigned.
+- The cpupool Pool-1 will have 2 cpus assigned.
+- The cpupool Pool-2 will have 2 cpus assigned (created by Xen with all the not
+  assigned cpus a53_3 and a53_4).
+
+chosen {
+
+    cpupool_a {
+        compatible = "xen,cpupool";
+        cpupool-cpus = <&a53_1 &a53_2>;
+    };
+    cpupool_b {
+        compatible = "xen,cpupool";
+        cpupool-cpus = <&a72_1 &a72_2>;
+        cpupool-sched = "null";
+    };
+
+    [...]
+
+};
diff --git a/xen/arch/arm/include/asm/smp.h b/xen/arch/arm/include/asm/smp.h
index af5a2fe65266..83c0cd69767b 100644
--- a/xen/arch/arm/include/asm/smp.h
+++ b/xen/arch/arm/include/asm/smp.h
@@ -34,6 +34,9 @@ extern void init_secondary(void);
 extern void smp_init_cpus(void);
 extern void smp_clear_cpu_maps (void);
 extern int smp_get_max_cpus (void);
+
+#define cpu_physical_id(cpu) cpu_logical_map(cpu)
+
 #endif
 
 /*
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index d921c74d615e..70aac5220e75 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -22,6 +22,13 @@ config GRANT_TABLE
 
 	  If unsure, say Y.
 
+config BOOT_TIME_CPUPOOLS
+	bool "Create cpupools at boot time"
+	depends on HAS_DEVICE_TREE
+	help
+	  Creates cpupools during boot time and assigns cpus to them. Cpupools
+	  options can be specified in the device tree.
+
 config ALTERNATIVE_CALL
 	bool
 
diff --git a/xen/common/Makefile b/xen/common/Makefile
index dc8d3a13f5b8..c5949785ab28 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -1,5 +1,6 @@
 obj-$(CONFIG_ARGO) += argo.o
 obj-y += bitmap.o
+obj-$(CONFIG_BOOT_TIME_CPUPOOLS) += boot_cpupools.o
 obj-$(CONFIG_HYPFS_CONFIG) += config_data.o
 obj-$(CONFIG_CORE_PARKING) += core_parking.o
 obj-y += cpu.o
diff --git a/xen/common/boot_cpupools.c b/xen/common/boot_cpupools.c
new file mode 100644
index 000000000000..f6f2fa8f2701
--- /dev/null
+++ b/xen/common/boot_cpupools.c
@@ -0,0 +1,178 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * xen/common/boot_cpupools.c
+ *
+ * Code to create cpupools at boot time.
+ *
+ * Copyright (C) 2022 Arm Ltd.
+ */
+
+#include <xen/sched.h>
+
+/*
+ * pool_cpu_map:   Index is logical cpu number, content is cpupool id, (-1) for
+ *                 unassigned.
+ * pool_sched_map: Index is cpupool id, content is scheduler id, (-1) for
+ *                 unassigned.
+ */
+static int __initdata pool_cpu_map[NR_CPUS]   = { [0 ... NR_CPUS-1] = -1 };
+static int __initdata pool_sched_map[NR_CPUS] = { [0 ... NR_CPUS-1] = -1 };
+static unsigned int __initdata next_pool_id;
+
+#ifdef CONFIG_HAS_DEVICE_TREE
+
+#define BTCPUPOOLS_DT_NODE_NO_REG     (-1)
+#define BTCPUPOOLS_DT_NODE_NO_LOG_CPU (-2)
+
+static int __init get_logical_cpu_from_hw_id(unsigned int hwid)
+{
+    unsigned int i;
+
+    for ( i = 0; i < nr_cpu_ids; i++ )
+        if ( cpu_physical_id(i) == hwid )
+            return i;
+
+    return -1;
+}
+
+static int __init
+get_logical_cpu_from_cpu_node(const struct dt_device_node *cpu_node)
+{
+    int cpu_num;
+    const __be32 *prop;
+    unsigned int cpu_reg;
+
+    prop = dt_get_property(cpu_node, "reg", NULL);
+    if ( !prop )
+        return BTCPUPOOLS_DT_NODE_NO_REG;
+
+    cpu_reg = dt_read_number(prop, dt_n_addr_cells(cpu_node));
+
+    cpu_num = get_logical_cpu_from_hw_id(cpu_reg);
+    if ( cpu_num < 0 )
+        return BTCPUPOOLS_DT_NODE_NO_LOG_CPU;
+
+    return cpu_num;
+}
+
+static int __init check_and_get_sched_id(const char* scheduler_name)
+{
+    int sched_id = sched_get_id_by_name(scheduler_name);
+
+    if ( sched_id < 0 )
+        panic("Scheduler %s does not exists!\n", scheduler_name);
+
+    return sched_id;
+}
+
+void __init btcpupools_dtb_parse(void)
+{
+    const struct dt_device_node *chosen, *node;
+
+    chosen = dt_find_node_by_path("/chosen");
+    if ( !chosen )
+        return;
+
+    dt_for_each_child_node(chosen, node)
+    {
+        const struct dt_device_node *phandle_node;
+        int sched_id = -1;
+        const char* scheduler_name;
+        unsigned int i = 0;
+
+        if ( !dt_device_is_compatible(node, "xen,cpupool") )
+            continue;
+
+        if ( !dt_property_read_string(phandle_node, "cpupool-sched",
+                                      &scheduler_name) )
+            sched_id = check_and_get_sched_id(scheduler_name);
+
+        phandle_node = dt_parse_phandle(node, "cpupool-cpus", i++);
+        if ( !phandle_node )
+            panic("Missing or empty cpupool-cpus property!\n");
+
+        while ( phandle_node )
+        {
+            int cpu_num;
+
+            cpu_num = get_logical_cpu_from_cpu_node(phandle_node);
+
+            if ( cpu_num < 0 )
+                panic("Error retrieving logical cpu from node %s (%d)\n",
+                      dt_node_name(node), cpu_num);
+
+            if ( pool_cpu_map[cpu_num] != -1 )
+                panic("Logical cpu %d already added to a cpupool!\n", cpu_num);
+
+            pool_cpu_map[cpu_num] = next_pool_id;
+            pool_sched_map[next_pool_id] = sched_id;
+
+            phandle_node = dt_parse_phandle(node, "cpupool-cpus", i++);
+        }
+
+        /* Let Xen generate pool ids */
+        next_pool_id++;
+    }
+}
+#endif
+
+void __init btcpupools_allocate_pools(void)
+{
+    unsigned int i;
+    bool add_extra_cpupool = false;
+
+    /*
+     * If there are no cpupools, the value of next_pool_id is zero, so the code
+     * below will assign every cpu to cpupool0 as the default behavior.
+     * When there are cpupools, the code below is assigning all the not
+     * assigned cpu to a new pool (next_pool_id value is the last id + 1).
+     * In the same loop we check if there is any assigned cpu that is not
+     * online.
+     */
+    for ( i = 0; i < nr_cpu_ids; i++ )
+        if ( cpumask_test_cpu(i, &cpu_online_map) )
+        {
+            /* Unassigned cpu gets next_pool_id pool id value */
+            if ( pool_cpu_map[i] < 0 )
+            {
+                pool_cpu_map[i] = next_pool_id;
+                add_extra_cpupool = true;
+            }
+            printk(XENLOG_INFO "Logical CPU %u in Pool-%u.\n", i,
+                   pool_cpu_map[i]);
+        }
+        else
+        {
+            if ( pool_cpu_map[i] >= 0 )
+                panic("Pool-%d contains cpu%u that is not online!\n",
+                      pool_cpu_map[i], i);
+        }
+
+    if ( add_extra_cpupool )
+        next_pool_id++;
+
+    /* Create cpupools with selected schedulers */
+    for ( i = 0; i < next_pool_id; i++ )
+        cpupool_create_pool(i, pool_sched_map[i]);
+
+#ifdef CONFIG_X86
+    /* Cpu0 must be in cpupool0 for x86 */
+    if ( pool_cpu_map[0] != 0 )
+        panic("Cpu0 must be in Pool-0\n");
+#endif
+}
+
+unsigned int __init btcpupools_get_cpupool_id(unsigned int cpu)
+{
+    return pool_cpu_map[cpu];
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/common/sched/cpupool.c b/xen/common/sched/cpupool.c
index 89a891af7076..e5189c53a321 100644
--- a/xen/common/sched/cpupool.c
+++ b/xen/common/sched/cpupool.c
@@ -1247,12 +1247,19 @@ static int __init cf_check cpupool_init(void)
     cpupool_put(cpupool0);
     register_cpu_notifier(&cpu_nfb);
 
+    btcpupools_dtb_parse();
+
+    btcpupools_allocate_pools();
+
     spin_lock(&cpupool_lock);
 
     cpumask_copy(&cpupool_free_cpus, &cpu_online_map);
 
     for_each_cpu ( cpu, &cpupool_free_cpus )
-        cpupool_assign_cpu_locked(cpupool0, cpu);
+    {
+        unsigned int pool_id = btcpupools_get_cpupool_id(cpu);
+        cpupool_assign_cpu_locked(cpupool_find_by_id(pool_id), cpu);
+    }
 
     spin_unlock(&cpupool_lock);
 
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 4050e22544f9..5d83465d3915 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -1176,6 +1176,25 @@ extern void cf_check dump_runq(unsigned char key);
 
 void arch_do_physinfo(struct xen_sysctl_physinfo *pi);
 
+#ifdef CONFIG_BOOT_TIME_CPUPOOLS
+void btcpupools_allocate_pools(void);
+unsigned int btcpupools_get_cpupool_id(unsigned int cpu);
+
+#ifdef CONFIG_HAS_DEVICE_TREE
+void btcpupools_dtb_parse(void);
+#else
+static inline void btcpupools_dtb_parse(void) {}
+#endif
+
+#else /* !CONFIG_BOOT_TIME_CPUPOOLS */
+static inline void btcpupools_allocate_pools(void) {}
+static inline void btcpupools_dtb_parse(void) {}
+static inline unsigned int btcpupools_get_cpupool_id(unsigned int cpu)
+{
+    return 0;
+}
+#endif
+
 #endif /* __SCHED_H__ */
 
 /*
-- 
2.17.1

[PATCH v3 5/6] arm/dom0less: assign dom0less guests to cpupools

[Luca Fancellu]

Introduce domain-cpupool property of a xen,domain device tree node,
that specifies the cpupool device tree handle of a xen,cpupool node
that identifies a cpupool created at boot time where the guest will
be assigned on creation.

Add member to the xen_domctl_createdomain public interface so the
XEN_DOMCTL_INTERFACE_VERSION version is bumped.

Add public function to retrieve a pool id from the device tree
cpupool node.

Update documentation about the property.

Signed-off-by: Luca Fancellu <luca.fancellu@arm.com>
---
Changes in v3:
- Use explicitely sized integer for struct xen_domctl_createdomain
  cpupool_id member. (Stefano)
- Changed code due to previous commit code changes
Changes in v2:
- Moved cpupool_id from arch specific to common part (Juergen)
- Implemented functions to retrieve the cpupool id from the
  cpupool dtb node.
---
 docs/misc/arm/device-tree/booting.txt |  5 +++++
 xen/arch/arm/domain_build.c           | 14 +++++++++++++-
 xen/common/boot_cpupools.c            | 24 ++++++++++++++++++++++++
 xen/common/domain.c                   |  2 +-
 xen/include/public/domctl.h           |  4 +++-
 xen/include/xen/sched.h               |  9 +++++++++
 6 files changed, 55 insertions(+), 3 deletions(-)

diff --git a/docs/misc/arm/device-tree/booting.txt b/docs/misc/arm/device-tree/booting.txt
index a94125394e35..7b4a29a2c293 100644
--- a/docs/misc/arm/device-tree/booting.txt
+++ b/docs/misc/arm/device-tree/booting.txt
@@ -188,6 +188,11 @@ with the following properties:
     An empty property to request the memory of the domain to be
     direct-map (guest physical address == physical address).
 
+- domain-cpupool
+
+    Optional. Handle to a xen,cpupool device tree node that identifies the
+    cpupool where the guest will be started at boot.
+
 Under the "xen,domain" compatible node, one or more sub-nodes are present
 for the DomU kernel and ramdisk.
 
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 8be01678de05..9c67a483d4a4 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -3172,7 +3172,8 @@ static int __init construct_domU(struct domain *d,
 void __init create_domUs(void)
 {
     struct dt_device_node *node;
-    const struct dt_device_node *chosen = dt_find_node_by_path("/chosen");
+    const struct dt_device_node *cpupool_node,
+                                *chosen = dt_find_node_by_path("/chosen");
 
     BUG_ON(chosen == NULL);
     dt_for_each_child_node(chosen, node)
@@ -3241,6 +3242,17 @@ void __init create_domUs(void)
                                          vpl011_virq - 32 + 1);
         }
 
+        /* Get the optional property domain-cpupool */
+        cpupool_node = dt_parse_phandle(node, "domain-cpupool", 0);
+        if ( cpupool_node )
+        {
+            int pool_id = btcpupools_get_domain_pool_id(cpupool_node);
+            if ( pool_id < 0 )
+                panic("Error getting cpupool id from domain-cpupool (%d)\n",
+                      pool_id);
+            d_cfg.cpupool_id = pool_id;
+        }
+
         /*
          * The variable max_init_domid is initialized with zero, so here it's
          * very important to use the pre-increment operator to call
diff --git a/xen/common/boot_cpupools.c b/xen/common/boot_cpupools.c
index f6f2fa8f2701..feba93a243fc 100644
--- a/xen/common/boot_cpupools.c
+++ b/xen/common/boot_cpupools.c
@@ -23,6 +23,8 @@ static unsigned int __initdata next_pool_id;
 
 #define BTCPUPOOLS_DT_NODE_NO_REG     (-1)
 #define BTCPUPOOLS_DT_NODE_NO_LOG_CPU (-2)
+#define BTCPUPOOLS_DT_WRONG_NODE      (-3)
+#define BTCPUPOOLS_DT_CORRUPTED_NODE  (-4)
 
 static int __init get_logical_cpu_from_hw_id(unsigned int hwid)
 {
@@ -55,6 +57,28 @@ get_logical_cpu_from_cpu_node(const struct dt_device_node *cpu_node)
     return cpu_num;
 }
 
+int __init btcpupools_get_domain_pool_id(const struct dt_device_node *node)
+{
+    const struct dt_device_node *phandle_node;
+    int cpu_num;
+
+    if ( !dt_device_is_compatible(node, "xen,cpupool") )
+        return BTCPUPOOLS_DT_WRONG_NODE;
+    /*
+     * Get first cpu listed in the cpupool, from its reg it's possible to
+     * retrieve the cpupool id.
+     */
+    phandle_node = dt_parse_phandle(node, "cpupool-cpus", 0);
+    if ( !phandle_node )
+        return BTCPUPOOLS_DT_CORRUPTED_NODE;
+
+    cpu_num = get_logical_cpu_from_cpu_node(phandle_node);
+    if ( cpu_num < 0 )
+        return cpu_num;
+
+    return pool_cpu_map[cpu_num];
+}
+
 static int __init check_and_get_sched_id(const char* scheduler_name)
 {
     int sched_id = sched_get_id_by_name(scheduler_name);
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 351029f8b239..0827400f4f49 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -698,7 +698,7 @@ struct domain *domain_create(domid_t domid,
         if ( !d->pbuf )
             goto fail;
 
-        if ( (err = sched_init_domain(d, 0)) != 0 )
+        if ( (err = sched_init_domain(d, config->cpupool_id)) != 0 )
             goto fail;
 
         if ( (err = late_hwdom_init(d)) != 0 )
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index b85e6170b0aa..2f4cf56f438d 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -38,7 +38,7 @@
 #include "hvm/save.h"
 #include "memory.h"
 
-#define XEN_DOMCTL_INTERFACE_VERSION 0x00000014
+#define XEN_DOMCTL_INTERFACE_VERSION 0x00000015
 
 /*
  * NB. xen_domctl.domain is an IN/OUT parameter for this operation.
@@ -106,6 +106,8 @@ struct xen_domctl_createdomain {
     /* Per-vCPU buffer size in bytes.  0 to disable. */
     uint32_t vmtrace_size;
 
+    uint32_t cpupool_id;
+
     struct xen_arch_domainconfig arch;
 };
 
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 5d83465d3915..4e749a604f25 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -1182,6 +1182,7 @@ unsigned int btcpupools_get_cpupool_id(unsigned int cpu);
 
 #ifdef CONFIG_HAS_DEVICE_TREE
 void btcpupools_dtb_parse(void);
+int btcpupools_get_domain_pool_id(const struct dt_device_node *node);
 #else
 static inline void btcpupools_dtb_parse(void) {}
 #endif
@@ -1193,6 +1194,14 @@ static inline unsigned int btcpupools_get_cpupool_id(unsigned int cpu)
 {
     return 0;
 }
+#ifdef CONFIG_HAS_DEVICE_TREE
+static inline int
+btcpupools_get_domain_pool_id(const struct dt_device_node *node)
+{
+    return 0;
+}
+#endif
+
 #endif
 
 #endif /* __SCHED_H__ */
-- 
2.17.1

[PATCH v3 6/6] xen/cpupool: Allow cpupool0 to use different scheduler

[Luca Fancellu]

Currently cpupool0 can use only the default scheduler, and
cpupool_create has an hardcoded behavior when creating the pool 0
that doesn't allocate new memory for the scheduler, but uses the
default scheduler structure in memory.

With this commit it is possible to allocate a different scheduler for
the cpupool0 when using the boot time cpupool.
To achieve this the hardcoded behavior in cpupool_create is removed
and the cpupool0 creation is moved.

When compiling without boot time cpupools enabled, the current
behavior is maintained (except that cpupool0 scheduler memory will be
allocated).

Signed-off-by: Luca Fancellu <luca.fancellu@arm.com>
---
Changes in v3:
- fix typo in commit message (Juergen)
- rebase changes
Changes in v2:
- new patch
---
 xen/common/boot_cpupools.c | 5 ++++-
 xen/common/sched/cpupool.c | 8 +-------
 xen/include/xen/sched.h    | 5 ++++-
 3 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/xen/common/boot_cpupools.c b/xen/common/boot_cpupools.c
index feba93a243fc..af5bea0c1113 100644
--- a/xen/common/boot_cpupools.c
+++ b/xen/common/boot_cpupools.c
@@ -175,8 +175,11 @@ void __init btcpupools_allocate_pools(void)
     if ( add_extra_cpupool )
         next_pool_id++;
 
+    /* Keep track of cpupool id 0 with the global cpupool0 */
+    cpupool0 = cpupool_create_pool(0, pool_sched_map[0]);
+
     /* Create cpupools with selected schedulers */
-    for ( i = 0; i < next_pool_id; i++ )
+    for ( i = 1; i < next_pool_id; i++ )
         cpupool_create_pool(i, pool_sched_map[i]);
 
 #ifdef CONFIG_X86
diff --git a/xen/common/sched/cpupool.c b/xen/common/sched/cpupool.c
index e5189c53a321..f717ee844e91 100644
--- a/xen/common/sched/cpupool.c
+++ b/xen/common/sched/cpupool.c
@@ -312,10 +312,7 @@ static struct cpupool *cpupool_create(unsigned int poolid,
         c->cpupool_id = q->cpupool_id + 1;
     }
 
-    if ( poolid == 0 )
-        c->sched = scheduler_get_default();
-    else
-        c->sched = scheduler_alloc(sched_id);
+    c->sched = scheduler_alloc(sched_id);
     if ( IS_ERR(c->sched) )
     {
         ret = PTR_ERR(c->sched);
@@ -1242,9 +1239,6 @@ static int __init cf_check cpupool_init(void)
 
     cpupool_hypfs_init();
 
-    cpupool0 = cpupool_create(0, 0);
-    BUG_ON(IS_ERR(cpupool0));
-    cpupool_put(cpupool0);
     register_cpu_notifier(&cpu_nfb);
 
     btcpupools_dtb_parse();
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 4e749a604f25..215b4f45609a 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -1188,7 +1188,10 @@ static inline void btcpupools_dtb_parse(void) {}
 #endif
 
 #else /* !CONFIG_BOOT_TIME_CPUPOOLS */
-static inline void btcpupools_allocate_pools(void) {}
+static inline void btcpupools_allocate_pools(void)
+{
+    cpupool0 = cpupool_create_pool(0, -1);
+}
 static inline void btcpupools_dtb_parse(void) {}
 static inline unsigned int btcpupools_get_cpupool_id(unsigned int cpu)
 {
-- 
2.17.1

Re: [PATCH v3 4/6] xen/cpupool: Create different cpupools at boot time

[Julien Grall]

Hi Luca,

I only skimmed through the series. I have one question below:

On 18/03/2022 15:25, Luca Fancellu wrote:
> +void __init btcpupools_allocate_pools(void)
> +{
> +    unsigned int i;
> +    bool add_extra_cpupool = false;
> +
> +    /*
> +     * If there are no cpupools, the value of next_pool_id is zero, so the code
> +     * below will assign every cpu to cpupool0 as the default behavior.
> +     * When there are cpupools, the code below is assigning all the not
> +     * assigned cpu to a new pool (next_pool_id value is the last id + 1).
> +     * In the same loop we check if there is any assigned cpu that is not
> +     * online.
> +     */
> +    for ( i = 0; i < nr_cpu_ids; i++ )
> +        if ( cpumask_test_cpu(i, &cpu_online_map) )
> +        {
> +            /* Unassigned cpu gets next_pool_id pool id value */
> +            if ( pool_cpu_map[i] < 0 )
> +            {
> +                pool_cpu_map[i] = next_pool_id;
> +                add_extra_cpupool = true;
> +            }
> +            printk(XENLOG_INFO "Logical CPU %u in Pool-%u.\n", i,
> +                   pool_cpu_map[i]);
> +        }
> +        else
> +        {
> +            if ( pool_cpu_map[i] >= 0 )
> +                panic("Pool-%d contains cpu%u that is not online!\n",
> +                      pool_cpu_map[i], i);
> +        }
> +
> +    if ( add_extra_cpupool )
> +        next_pool_id++;
> +
> +    /* Create cpupools with selected schedulers */
> +    for ( i = 0; i < next_pool_id; i++ )
> +        cpupool_create_pool(i, pool_sched_map[i]);
> +
> +#ifdef CONFIG_X86
> +    /* Cpu0 must be in cpupool0 for x86 */
> +    if ( pool_cpu_map[0] != 0 )
> +        panic("Cpu0 must be in Pool-0\n");
> +#endif

Can you document why this is necessary on x86 but not on other 
architectures?

Cheers,

-- 
Julien Grall

Re: [PATCH v3 5/6] arm/dom0less: assign dom0less guests to cpupools

[Julien Grall]

Hi,

On 18/03/2022 15:25, Luca Fancellu wrote:
> Introduce domain-cpupool property of a xen,domain device tree node,
> that specifies the cpupool device tree handle of a xen,cpupool node
> that identifies a cpupool created at boot time where the guest will
> be assigned on creation.
> 
> Add member to the xen_domctl_createdomain public interface so the
> XEN_DOMCTL_INTERFACE_VERSION version is bumped.
> 
> Add public function to retrieve a pool id from the device tree
> cpupool node.
> 
> Update documentation about the property.
> 
> Signed-off-by: Luca Fancellu <luca.fancellu@arm.com>
> ---
> Changes in v3:
> - Use explicitely sized integer for struct xen_domctl_createdomain
>    cpupool_id member. (Stefano)
> - Changed code due to previous commit code changes
> Changes in v2:
> - Moved cpupool_id from arch specific to common part (Juergen)
> - Implemented functions to retrieve the cpupool id from the
>    cpupool dtb node.
> ---
>   docs/misc/arm/device-tree/booting.txt |  5 +++++
>   xen/arch/arm/domain_build.c           | 14 +++++++++++++-
>   xen/common/boot_cpupools.c            | 24 ++++++++++++++++++++++++
>   xen/common/domain.c                   |  2 +-
>   xen/include/public/domctl.h           |  4 +++-
>   xen/include/xen/sched.h               |  9 +++++++++

This patch doesn't seem to contain any change in tools. So...

>           if ( (err = late_hwdom_init(d)) != 0 )
> diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
> index b85e6170b0aa..2f4cf56f438d 100644
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -38,7 +38,7 @@
>   #include "hvm/save.h"
>   #include "memory.h"
>   
> -#define XEN_DOMCTL_INTERFACE_VERSION 0x00000014
> +#define XEN_DOMCTL_INTERFACE_VERSION 0x00000015
>   
>   /*
>    * NB. xen_domctl.domain is an IN/OUT parameter for this operation.
> @@ -106,6 +106,8 @@ struct xen_domctl_createdomain {
>       /* Per-vCPU buffer size in bytes.  0 to disable. */
>       uint32_t vmtrace_size;
>   
> +    uint32_t cpupool_id;

... will the tools (e.g. golang bindings, libxl,..) always zero 
xen_domctl_createdomain?

I also think we may need to regenerate the golang bindings.

Cheers,

-- 
Julien Grall

Re: [PATCH v3 5/6] arm/dom0less: assign dom0less guests to cpupools

[Jan Beulich]

On 18.03.2022 16:25, Luca Fancellu wrote:
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -1182,6 +1182,7 @@ unsigned int btcpupools_get_cpupool_id(unsigned int cpu);
>  
>  #ifdef CONFIG_HAS_DEVICE_TREE
>  void btcpupools_dtb_parse(void);
> +int btcpupools_get_domain_pool_id(const struct dt_device_node *node);
>  #else
>  static inline void btcpupools_dtb_parse(void) {}
>  #endif
> @@ -1193,6 +1194,14 @@ static inline unsigned int btcpupools_get_cpupool_id(unsigned int cpu)
>  {
>      return 0;
>  }
> +#ifdef CONFIG_HAS_DEVICE_TREE
> +static inline int
> +btcpupools_get_domain_pool_id(const struct dt_device_node *node)
> +{
> +    return 0;
> +}
> +#endif

Was this perhaps meant to go inside the #else visible in the context of
the earlier hunk? It's odd in any event that you have #ifdef twice, not
once #ifdef and once #ifndef.

Jan

Re: [PATCH v3 4/6] xen/cpupool: Create different cpupools at boot time

[Jan Beulich]

On 18.03.2022 16:25, Luca Fancellu wrote:
> --- a/xen/common/Makefile
> +++ b/xen/common/Makefile
> @@ -1,5 +1,6 @@
>  obj-$(CONFIG_ARGO) += argo.o
>  obj-y += bitmap.o
> +obj-$(CONFIG_BOOT_TIME_CPUPOOLS) += boot_cpupools.o

By the looks of it you appear to want to specify boot_cpupools.init.o
here: All functions there are __init and all data is __initdata. That
was string literals (e.g. as used for printk() invocations) will also
move to .init.*.

> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -1176,6 +1176,25 @@ extern void cf_check dump_runq(unsigned char key);
>  
>  void arch_do_physinfo(struct xen_sysctl_physinfo *pi);
>  
> +#ifdef CONFIG_BOOT_TIME_CPUPOOLS
> +void btcpupools_allocate_pools(void);
> +unsigned int btcpupools_get_cpupool_id(unsigned int cpu);
> +
> +#ifdef CONFIG_HAS_DEVICE_TREE
> +void btcpupools_dtb_parse(void);
> +#else
> +static inline void btcpupools_dtb_parse(void) {}

I think you want to avoid having two stubs for this - one here and ...

> +#endif
> +
> +#else /* !CONFIG_BOOT_TIME_CPUPOOLS */
> +static inline void btcpupools_allocate_pools(void) {}
> +static inline void btcpupools_dtb_parse(void) {}

... another one here.

Jan

Re: [PATCH v3 4/6] xen/cpupool: Create different cpupools at boot time

[Luca Fancellu]

> On 21 Mar 2022, at 09:10, Jan Beulich <jbeulich@suse.com> wrote:
> 
> On 18.03.2022 16:25, Luca Fancellu wrote:
>> --- a/xen/common/Makefile
>> +++ b/xen/common/Makefile
>> @@ -1,5 +1,6 @@
>> obj-$(CONFIG_ARGO) += argo.o
>> obj-y += bitmap.o
>> +obj-$(CONFIG_BOOT_TIME_CPUPOOLS) += boot_cpupools.o
> 
> By the looks of it you appear to want to specify boot_cpupools.init.o
> here: All functions there are __init and all data is __initdata. That
> was string literals (e.g. as used for printk() invocations) will also
> move to .init.*.
> 
>> --- a/xen/include/xen/sched.h
>> +++ b/xen/include/xen/sched.h
>> @@ -1176,6 +1176,25 @@ extern void cf_check dump_runq(unsigned char key);
>> 
>> void arch_do_physinfo(struct xen_sysctl_physinfo *pi);
>> 
>> +#ifdef CONFIG_BOOT_TIME_CPUPOOLS
>> +void btcpupools_allocate_pools(void);
>> +unsigned int btcpupools_get_cpupool_id(unsigned int cpu);
>> +
>> +#ifdef CONFIG_HAS_DEVICE_TREE
>> +void btcpupools_dtb_parse(void);
>> +#else
>> +static inline void btcpupools_dtb_parse(void) {}
> 
> I think you want to avoid having two stubs for this - one here and ...
> 
>> +#endif
>> +
>> +#else /* !CONFIG_BOOT_TIME_CPUPOOLS */
>> +static inline void btcpupools_allocate_pools(void) {}
>> +static inline void btcpupools_dtb_parse(void) {}
> 
> ... another one here.
> 

Hi Jan,

Thank you for your review, yes I will fix your findings in the next serie.

Cheers,
Luca

> Jan
> 
> 

Re: [PATCH v3 4/6] xen/cpupool: Create different cpupools at boot time

[Luca Fancellu]

> On 18 Mar 2022, at 16:12, Julien Grall <julien@xen.org> wrote:
> 
> Hi Luca,
> 
> I only skimmed through the series. I have one question below:
> 
> On 18/03/2022 15:25, Luca Fancellu wrote:
>> +void __init btcpupools_allocate_pools(void)
>> +{
>> +    unsigned int i;
>> +    bool add_extra_cpupool = false;
>> +
>> +    /*
>> +     * If there are no cpupools, the value of next_pool_id is zero, so the code
>> +     * below will assign every cpu to cpupool0 as the default behavior.
>> +     * When there are cpupools, the code below is assigning all the not
>> +     * assigned cpu to a new pool (next_pool_id value is the last id + 1).
>> +     * In the same loop we check if there is any assigned cpu that is not
>> +     * online.
>> +     */
>> +    for ( i = 0; i < nr_cpu_ids; i++ )
>> +        if ( cpumask_test_cpu(i, &cpu_online_map) )
>> +        {
>> +            /* Unassigned cpu gets next_pool_id pool id value */
>> +            if ( pool_cpu_map[i] < 0 )
>> +            {
>> +                pool_cpu_map[i] = next_pool_id;
>> +                add_extra_cpupool = true;
>> +            }
>> +            printk(XENLOG_INFO "Logical CPU %u in Pool-%u.\n", i,
>> +                   pool_cpu_map[i]);
>> +        }
>> +        else
>> +        {
>> +            if ( pool_cpu_map[i] >= 0 )
>> +                panic("Pool-%d contains cpu%u that is not online!\n",
>> +                      pool_cpu_map[i], i);
>> +        }
>> +
>> +    if ( add_extra_cpupool )
>> +        next_pool_id++;
>> +
>> +    /* Create cpupools with selected schedulers */
>> +    for ( i = 0; i < next_pool_id; i++ )
>> +        cpupool_create_pool(i, pool_sched_map[i]);
>> +
>> +#ifdef CONFIG_X86
>> +    /* Cpu0 must be in cpupool0 for x86 */
>> +    if ( pool_cpu_map[0] != 0 )
>> +        panic("Cpu0 must be in Pool-0\n");
>> +#endif
> 
> Can you document why this is necessary on x86 but not on other architectures?

Hi Julien,

I received the warning by Juergen here: https://patchwork.kernel.org/comment/24740762/ that at least on x86 there could be
some problems if cpu0 is not in cpupool0, I tested it on arm and it was working fine and I didn’t find any restriction.

So I don’t know why on x86 we must have cpu0 in cpupool0, maybe x86 maintainer have more knowledge about that and
I can put a comment here.

Cheers,
Luca

> 
> Cheers,
> 
> -- 
> Julien Grall

Re: [PATCH v3 4/6] xen/cpupool: Create different cpupools at boot time

[Julien Grall]

Hi,

On 21/03/2022 15:58, Luca Fancellu wrote:
> 
> 
>> On 18 Mar 2022, at 16:12, Julien Grall <julien@xen.org> wrote:
>>
>> Hi Luca,
>>
>> I only skimmed through the series. I have one question below:
>>
>> On 18/03/2022 15:25, Luca Fancellu wrote:
>>> +void __init btcpupools_allocate_pools(void)
>>> +{
>>> +    unsigned int i;
>>> +    bool add_extra_cpupool = false;
>>> +
>>> +    /*
>>> +     * If there are no cpupools, the value of next_pool_id is zero, so the code
>>> +     * below will assign every cpu to cpupool0 as the default behavior.
>>> +     * When there are cpupools, the code below is assigning all the not
>>> +     * assigned cpu to a new pool (next_pool_id value is the last id + 1).
>>> +     * In the same loop we check if there is any assigned cpu that is not
>>> +     * online.
>>> +     */
>>> +    for ( i = 0; i < nr_cpu_ids; i++ )
>>> +        if ( cpumask_test_cpu(i, &cpu_online_map) )
>>> +        {
>>> +            /* Unassigned cpu gets next_pool_id pool id value */
>>> +            if ( pool_cpu_map[i] < 0 )
>>> +            {
>>> +                pool_cpu_map[i] = next_pool_id;
>>> +                add_extra_cpupool = true;
>>> +            }
>>> +            printk(XENLOG_INFO "Logical CPU %u in Pool-%u.\n", i,
>>> +                   pool_cpu_map[i]);
>>> +        }
>>> +        else
>>> +        {
>>> +            if ( pool_cpu_map[i] >= 0 )
>>> +                panic("Pool-%d contains cpu%u that is not online!\n",
>>> +                      pool_cpu_map[i], i);
>>> +        }
>>> +
>>> +    if ( add_extra_cpupool )
>>> +        next_pool_id++;
>>> +
>>> +    /* Create cpupools with selected schedulers */
>>> +    for ( i = 0; i < next_pool_id; i++ )
>>> +        cpupool_create_pool(i, pool_sched_map[i]);
>>> +
>>> +#ifdef CONFIG_X86
>>> +    /* Cpu0 must be in cpupool0 for x86 */
>>> +    if ( pool_cpu_map[0] != 0 )
>>> +        panic("Cpu0 must be in Pool-0\n");
>>> +#endif
>>
>> Can you document why this is necessary on x86 but not on other architectures?
> 
> Hi Julien,
> 
> I received the warning by Juergen here: https://patchwork.kernel.org/comment/24740762/ that at least on x86 there could be
> some problems if cpu0 is not in cpupool0, I tested it on arm and it was working fine and I didn’t find any restriction.

What exactly did you test on Arm?

> 
> So I don’t know why on x86 we must have cpu0 in cpupool0, maybe x86 maintainer have more knowledge about that and
> I can put a comment here.

On Arm, we are not yet supporting all the CPU features that x86 supports 
(e.g. CPU hotplug, suspend/resume...). So I a am bit concerned that the 
restriction is just not there yet (or possibly hidden).

Therefore, before lifting the restriction on Arm (and other arch), I 
would like us to understand why it is necessary on x86.

We may not have the answer quickly, so is it going to be a problem to 
keep the restriction on Arm?

Cheers,

-- 
Julien Grall

Re: [PATCH v3 4/6] xen/cpupool: Create different cpupools at boot time

[Bertrand Marquis]

Hi Julien,

> On 21 Mar 2022, at 17:36, Julien Grall <julien@xen.org> wrote:
> 
> Hi,
> 
> On 21/03/2022 15:58, Luca Fancellu wrote:
>>> On 18 Mar 2022, at 16:12, Julien Grall <julien@xen.org> wrote:
>>> 
>>> Hi Luca,
>>> 
>>> I only skimmed through the series. I have one question below:
>>> 
>>> On 18/03/2022 15:25, Luca Fancellu wrote:
>>>> +void __init btcpupools_allocate_pools(void)
>>>> +{
>>>> +    unsigned int i;
>>>> +    bool add_extra_cpupool = false;
>>>> +
>>>> +    /*
>>>> +     * If there are no cpupools, the value of next_pool_id is zero, so the code
>>>> +     * below will assign every cpu to cpupool0 as the default behavior.
>>>> +     * When there are cpupools, the code below is assigning all the not
>>>> +     * assigned cpu to a new pool (next_pool_id value is the last id + 1).
>>>> +     * In the same loop we check if there is any assigned cpu that is not
>>>> +     * online.
>>>> +     */
>>>> +    for ( i = 0; i < nr_cpu_ids; i++ )
>>>> +        if ( cpumask_test_cpu(i, &cpu_online_map) )
>>>> +        {
>>>> +            /* Unassigned cpu gets next_pool_id pool id value */
>>>> +            if ( pool_cpu_map[i] < 0 )
>>>> +            {
>>>> +                pool_cpu_map[i] = next_pool_id;
>>>> +                add_extra_cpupool = true;
>>>> +            }
>>>> +            printk(XENLOG_INFO "Logical CPU %u in Pool-%u.\n", i,
>>>> +                   pool_cpu_map[i]);
>>>> +        }
>>>> +        else
>>>> +        {
>>>> +            if ( pool_cpu_map[i] >= 0 )
>>>> +                panic("Pool-%d contains cpu%u that is not online!\n",
>>>> +                      pool_cpu_map[i], i);
>>>> +        }
>>>> +
>>>> +    if ( add_extra_cpupool )
>>>> +        next_pool_id++;
>>>> +
>>>> +    /* Create cpupools with selected schedulers */
>>>> +    for ( i = 0; i < next_pool_id; i++ )
>>>> +        cpupool_create_pool(i, pool_sched_map[i]);
>>>> +
>>>> +#ifdef CONFIG_X86
>>>> +    /* Cpu0 must be in cpupool0 for x86 */
>>>> +    if ( pool_cpu_map[0] != 0 )
>>>> +        panic("Cpu0 must be in Pool-0\n");
>>>> +#endif
>>> 
>>> Can you document why this is necessary on x86 but not on other architectures?
>> Hi Julien,
>> I received the warning by Juergen here: https://patchwork.kernel.org/comment/24740762/ that at least on x86 there could be
>> some problems if cpu0 is not in cpupool0, I tested it on arm and it was working fine and I didn’t find any restriction.
> 
> What exactly did you test on Arm?
> 
>> So I don’t know why on x86 we must have cpu0 in cpupool0, maybe x86 maintainer have more knowledge about that and
>> I can put a comment here.
> 
> On Arm, we are not yet supporting all the CPU features that x86 supports (e.g. CPU hotplug, suspend/resume...). So I a am bit concerned that the restriction is just not there yet (or possibly hidden).
> 
> Therefore, before lifting the restriction on Arm (and other arch), I would like us to understand why it is necessary on x86.
> 
> We may not have the answer quickly, so is it going to be a problem to keep the restriction on Arm?

I am ok to keep the limitation to have dom0 always running on cpu0.
Only limitation I can see is that on a big little system, dom0 needs to stay on the type of core of the first booted core.
But as the user could modify his firmware to boot on the type of core he wants, this limitation can usually be worked around.
So it is not a problem.
Maybe we could make that an unsupported feature that one could activate through the configuration ?

Cheers
Bertrand

> 
> Cheers,
> 
> -- 
> Julien Grall

Re: [PATCH v3 4/6] xen/cpupool: Create different cpupools at boot time

[Julien Grall]

Hi Bertrand,

On 21/03/2022 17:19, Bertrand Marquis wrote:
>> On 21 Mar 2022, at 17:36, Julien Grall <julien@xen.org> wrote:
>>> So I don’t know why on x86 we must have cpu0 in cpupool0, maybe x86 maintainer have more knowledge about that and
>>> I can put a comment here.
>>
>> On Arm, we are not yet supporting all the CPU features that x86 supports (e.g. CPU hotplug, suspend/resume...). So I a am bit concerned that the restriction is just not there yet (or possibly hidden).
>>
>> Therefore, before lifting the restriction on Arm (and other arch), I would like us to understand why it is necessary on x86.
>>
>> We may not have the answer quickly, so is it going to be a problem to keep the restriction on Arm?
> 
> I am ok to keep the limitation to have dom0 always running on cpu0.
> Only limitation I can see is that on a big little system, dom0 needs to stay on the type of core of the first booted core.

Where does this limitation come from?

Cheers,

-- 
Julien Grall

Re: [PATCH v3 4/6] xen/cpupool: Create different cpupools at boot time

[Stefano Stabellini]

On Fri, 18 Mar 2022, Luca Fancellu wrote:
> Introduce a way to create different cpupools at boot time, this is
> particularly useful on ARM big.LITTLE system where there might be the
> need to have different cpupools for each type of core, but also
> systems using NUMA can have different cpu pools for each node.
> 
> The feature on arm relies on a specification of the cpupools from the
> device tree to build pools and assign cpus to them.
> 
> Documentation is created to explain the feature.
> 
> Signed-off-by: Luca Fancellu <luca.fancellu@arm.com>
> ---
> Changes in v3:
> - Add newline to cpupools.txt and removed "default n" from Kconfig (Jan)
> - Fixed comment, moved defines, used global cpu_online_map, use
>   HAS_DEVICE_TREE instead of ARM and place arch specific code in header
>   (Juergen)
> - Fix brakets, x86 code only panic, get rid of scheduler dt node, don't
>   save pool pointer and look for it from the pool list (Stefano)
> - Changed data structures to allow modification to the code.
> Changes in v2:
> - Move feature to common code (Juergen)
> - Try to decouple dtb parse and cpupool creation to allow
>   more way to specify cpupools (for example command line)
> - Created standalone dt node for the scheduler so it can
>   be used in future work to set scheduler specific
>   parameters
> - Use only auto generated ids for cpupools
> ---
>  docs/misc/arm/device-tree/cpupools.txt | 135 +++++++++++++++++++
>  xen/arch/arm/include/asm/smp.h         |   3 +
>  xen/common/Kconfig                     |   7 +
>  xen/common/Makefile                    |   1 +
>  xen/common/boot_cpupools.c             | 178 +++++++++++++++++++++++++
>  xen/common/sched/cpupool.c             |   9 +-
>  xen/include/xen/sched.h                |  19 +++
>  7 files changed, 351 insertions(+), 1 deletion(-)
>  create mode 100644 docs/misc/arm/device-tree/cpupools.txt
>  create mode 100644 xen/common/boot_cpupools.c
> 
> diff --git a/docs/misc/arm/device-tree/cpupools.txt b/docs/misc/arm/device-tree/cpupools.txt
> new file mode 100644
> index 000000000000..6d7463736b48
> --- /dev/null
> +++ b/docs/misc/arm/device-tree/cpupools.txt
> @@ -0,0 +1,135 @@
> +Boot time cpupools
> +==================
> +
> +When BOOT_TIME_CPUPOOLS is enabled in the Xen configuration, it is possible to
> +create cpupools during boot phase by specifying them in the device tree.
> +
> +Cpupools specification nodes shall be direct childs of /chosen node.
> +Each cpupool node contains the following properties:
> +
> +- compatible (mandatory)
> +
> +    Must always include the compatiblity string: "xen,cpupool".
> +
> +- cpupool-cpus (mandatory)
> +
> +    Must be a list of device tree phandle to nodes describing cpus (e.g. having
> +    device_type = "cpu"), it can't be empty.
> +
> +- cpupool-sched (optional)
> +
> +    Must be a string having the name of a Xen scheduler, it has no effect when
> +    used in conjunction of a cpupool-id equal to zero, in that case the
> +    default Xen scheduler is selected (sched=<...> boot argument).
> +    Check the sched=<...> boot argument for allowed values.

I am happy with this version of the device tree bindings, thanks for
your efforts to update them. Only one comment left: please update the
description not to include "cpupool-id" given that there is no
cpupool-id property anymore :-)


> +Constraints
> +===========
> +
> +If no cpupools are specified, all cpus will be assigned to one cpupool
> +implicitly created (Pool-0).
> +
> +If cpupools node are specified, but not every cpu brought up by Xen is assigned,
> +all the not assigned cpu will be assigned to an additional cpupool.
> +
> +If a cpu is assigned to a cpupool, but it's not brought up correctly, Xen will
> +stop.
> +
> +
> +Examples
> +========
> +
> +A system having two types of core, the following device tree specification will
> +instruct Xen to have two cpupools:
> +
> +- The cpupool with id 0 will have 4 cpus assigned.
> +- The cpupool with id 1 will have 2 cpus assigned.
> +
> +The following example can work only if hmp-unsafe=1 is passed to Xen boot
> +arguments, otherwise not all cores will be brought up by Xen and the cpupool
> +creation process will stop Xen.
> +
> +
> +a72_1: cpu@0 {
> +        compatible = "arm,cortex-a72";
> +        reg = <0x0 0x0>;
> +        device_type = "cpu";
> +        [...]
> +};
> +
> +a72_2: cpu@1 {
> +        compatible = "arm,cortex-a72";
> +        reg = <0x0 0x1>;
> +        device_type = "cpu";
> +        [...]
> +};
> +
> +a53_1: cpu@100 {
> +        compatible = "arm,cortex-a53";
> +        reg = <0x0 0x100>;
> +        device_type = "cpu";
> +        [...]
> +};
> +
> +a53_2: cpu@101 {
> +        compatible = "arm,cortex-a53";
> +        reg = <0x0 0x101>;
> +        device_type = "cpu";
> +        [...]
> +};
> +
> +a53_3: cpu@102 {
> +        compatible = "arm,cortex-a53";
> +        reg = <0x0 0x102>;
> +        device_type = "cpu";
> +        [...]
> +};
> +
> +a53_4: cpu@103 {
> +        compatible = "arm,cortex-a53";
> +        reg = <0x0 0x103>;
> +        device_type = "cpu";
> +        [...]
> +};
> +
> +chosen {
> +
> +    cpupool_a {
> +        compatible = "xen,cpupool";
> +        cpupool-cpus = <&a53_1 &a53_2 &a53_3 &a53_4>;
> +    };
> +    cpupool_b {
> +        compatible = "xen,cpupool";
> +        cpupool-cpus = <&a72_1 &a72_2>;
> +        cpupool-sched = "credit2";
> +    };
> +
> +    [...]
> +
> +};
> +
> +
> +A system having the cpupools specification below will instruct Xen to have three
> +cpupools:
> +
> +- The cpupool Pool-0 will have 2 cpus assigned.
> +- The cpupool Pool-1 will have 2 cpus assigned.
> +- The cpupool Pool-2 will have 2 cpus assigned (created by Xen with all the not
> +  assigned cpus a53_3 and a53_4).
> +
> +chosen {
> +
> +    cpupool_a {
> +        compatible = "xen,cpupool";
> +        cpupool-cpus = <&a53_1 &a53_2>;
> +    };
> +    cpupool_b {
> +        compatible = "xen,cpupool";
> +        cpupool-cpus = <&a72_1 &a72_2>;
> +        cpupool-sched = "null";
> +    };
> +
> +    [...]
> +
> +};

I think it looks great, thanks!


> diff --git a/xen/arch/arm/include/asm/smp.h b/xen/arch/arm/include/asm/smp.h
> index af5a2fe65266..83c0cd69767b 100644
> --- a/xen/arch/arm/include/asm/smp.h
> +++ b/xen/arch/arm/include/asm/smp.h
> @@ -34,6 +34,9 @@ extern void init_secondary(void);
>  extern void smp_init_cpus(void);
>  extern void smp_clear_cpu_maps (void);
>  extern int smp_get_max_cpus (void);
> +
> +#define cpu_physical_id(cpu) cpu_logical_map(cpu)
> +
>  #endif
>  
>  /*
> diff --git a/xen/common/Kconfig b/xen/common/Kconfig
> index d921c74d615e..70aac5220e75 100644
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -22,6 +22,13 @@ config GRANT_TABLE
>  
>  	  If unsure, say Y.
>  
> +config BOOT_TIME_CPUPOOLS
> +	bool "Create cpupools at boot time"
> +	depends on HAS_DEVICE_TREE
> +	help
> +	  Creates cpupools during boot time and assigns cpus to them. Cpupools
> +	  options can be specified in the device tree.
> +
>  config ALTERNATIVE_CALL
>  	bool
>  
> diff --git a/xen/common/Makefile b/xen/common/Makefile
> index dc8d3a13f5b8..c5949785ab28 100644
> --- a/xen/common/Makefile
> +++ b/xen/common/Makefile
> @@ -1,5 +1,6 @@
>  obj-$(CONFIG_ARGO) += argo.o
>  obj-y += bitmap.o
> +obj-$(CONFIG_BOOT_TIME_CPUPOOLS) += boot_cpupools.o
>  obj-$(CONFIG_HYPFS_CONFIG) += config_data.o
>  obj-$(CONFIG_CORE_PARKING) += core_parking.o
>  obj-y += cpu.o
> diff --git a/xen/common/boot_cpupools.c b/xen/common/boot_cpupools.c
> new file mode 100644
> index 000000000000..f6f2fa8f2701
> --- /dev/null
> +++ b/xen/common/boot_cpupools.c
> @@ -0,0 +1,178 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * xen/common/boot_cpupools.c
> + *
> + * Code to create cpupools at boot time.
> + *
> + * Copyright (C) 2022 Arm Ltd.
> + */
> +
> +#include <xen/sched.h>
> +
> +/*
> + * pool_cpu_map:   Index is logical cpu number, content is cpupool id, (-1) for
> + *                 unassigned.
> + * pool_sched_map: Index is cpupool id, content is scheduler id, (-1) for
> + *                 unassigned.
> + */
> +static int __initdata pool_cpu_map[NR_CPUS]   = { [0 ... NR_CPUS-1] = -1 };
> +static int __initdata pool_sched_map[NR_CPUS] = { [0 ... NR_CPUS-1] = -1 };
> +static unsigned int __initdata next_pool_id;
> +
> +#ifdef CONFIG_HAS_DEVICE_TREE

BOOT_TIME_CPUPOOLS depends on HAS_DEVICE_TREE, so it is not possible to
have BOOT_TIME_CPUPOOLS but not HAS_DEVICE_TREE ?


> +#define BTCPUPOOLS_DT_NODE_NO_REG     (-1)
> +#define BTCPUPOOLS_DT_NODE_NO_LOG_CPU (-2)
> +
> +static int __init get_logical_cpu_from_hw_id(unsigned int hwid)
> +{
> +    unsigned int i;
> +
> +    for ( i = 0; i < nr_cpu_ids; i++ )
> +        if ( cpu_physical_id(i) == hwid )
> +            return i;
> +
> +    return -1;
> +}

I wonder if there is a better way to implement this function but I am
not sure. Also, it might be better to avoid premature optimizations.

That said, we could check first the simple case where hwid==i. Looking
at various existing device tree, it seems to be the most common case.

This is not a requirement, just a hand-wavy suggestion. I think the
patch is also OK as is.


> +static int __init
> +get_logical_cpu_from_cpu_node(const struct dt_device_node *cpu_node)
> +{
> +    int cpu_num;
> +    const __be32 *prop;
> +    unsigned int cpu_reg;
> +
> +    prop = dt_get_property(cpu_node, "reg", NULL);
> +    if ( !prop )
> +        return BTCPUPOOLS_DT_NODE_NO_REG;
> +
> +    cpu_reg = dt_read_number(prop, dt_n_addr_cells(cpu_node));
> +
> +    cpu_num = get_logical_cpu_from_hw_id(cpu_reg);
> +    if ( cpu_num < 0 )
> +        return BTCPUPOOLS_DT_NODE_NO_LOG_CPU;
> +
> +    return cpu_num;
> +}
> +
> +static int __init check_and_get_sched_id(const char* scheduler_name)
> +{
> +    int sched_id = sched_get_id_by_name(scheduler_name);
> +
> +    if ( sched_id < 0 )
> +        panic("Scheduler %s does not exists!\n", scheduler_name);
> +
> +    return sched_id;
> +}
> +
> +void __init btcpupools_dtb_parse(void)
> +{
> +    const struct dt_device_node *chosen, *node;
> +
> +    chosen = dt_find_node_by_path("/chosen");
> +    if ( !chosen )
> +        return;
> +
> +    dt_for_each_child_node(chosen, node)
> +    {
> +        const struct dt_device_node *phandle_node;
> +        int sched_id = -1;
> +        const char* scheduler_name;
> +        unsigned int i = 0;
> +
> +        if ( !dt_device_is_compatible(node, "xen,cpupool") )
> +            continue;
> +
> +        if ( !dt_property_read_string(phandle_node, "cpupool-sched",
> +                                      &scheduler_name) )
> +            sched_id = check_and_get_sched_id(scheduler_name);
> +
> +        phandle_node = dt_parse_phandle(node, "cpupool-cpus", i++);
> +        if ( !phandle_node )
> +            panic("Missing or empty cpupool-cpus property!\n");
> +
> +        while ( phandle_node )
> +        {
> +            int cpu_num;
> +
> +            cpu_num = get_logical_cpu_from_cpu_node(phandle_node);
> +
> +            if ( cpu_num < 0 )
> +                panic("Error retrieving logical cpu from node %s (%d)\n",
> +                      dt_node_name(node), cpu_num);
> +
> +            if ( pool_cpu_map[cpu_num] != -1 )
> +                panic("Logical cpu %d already added to a cpupool!\n", cpu_num);
> +
> +            pool_cpu_map[cpu_num] = next_pool_id;
> +            pool_sched_map[next_pool_id] = sched_id;
> +
> +            phandle_node = dt_parse_phandle(node, "cpupool-cpus", i++);
> +        }
> +
> +        /* Let Xen generate pool ids */
> +        next_pool_id++;
> +    }
> +}
> +#endif
> +
> +void __init btcpupools_allocate_pools(void)
> +{
> +    unsigned int i;
> +    bool add_extra_cpupool = false;
> +
> +    /*
> +     * If there are no cpupools, the value of next_pool_id is zero, so the code
> +     * below will assign every cpu to cpupool0 as the default behavior.
> +     * When there are cpupools, the code below is assigning all the not
> +     * assigned cpu to a new pool (next_pool_id value is the last id + 1).
> +     * In the same loop we check if there is any assigned cpu that is not
> +     * online.
> +     */
> +    for ( i = 0; i < nr_cpu_ids; i++ )
> +        if ( cpumask_test_cpu(i, &cpu_online_map) )

Let me take this opportunity to explain the unfortunately unwritten
coding style the way I understand it. I know this is tribal knowledge at
the moment and I apologize for that.

If it is a single line statement, we skip the { }, we keep them in all
other cases.

So:
 
  /* correct */
  if ( xxx ) {
      something;
      something else;
  }

  /* correct */
  if ( xxx ) {
      for ( yyy ) {
      }
  }

  /* correct */
  if ( xxx )
      something single line or 2 lines like a printk that go beyond 80
      chars, never in case of nested ifs

  /* not correct */
  if ( xxx )
      something
      multi
      line;

  /* not correct */
  if ( xxx )
      if ( yyy )
          something;

So basically we would keep the { } here but we would skip them ...


> +        {
> +            /* Unassigned cpu gets next_pool_id pool id value */
> +            if ( pool_cpu_map[i] < 0 )
> +            {
> +                pool_cpu_map[i] = next_pool_id;
> +                add_extra_cpupool = true;
> +            }
> +            printk(XENLOG_INFO "Logical CPU %u in Pool-%u.\n", i,
> +                   pool_cpu_map[i]);
> +        }
> +        else
> +        {
> +            if ( pool_cpu_map[i] >= 0 )
> +                panic("Pool-%d contains cpu%u that is not online!\n",
> +                      pool_cpu_map[i], i);

...skip them here


> +        }
> +
> +    if ( add_extra_cpupool )
> +        next_pool_id++;

...and skip them here


> +    /* Create cpupools with selected schedulers */
> +    for ( i = 0; i < next_pool_id; i++ )
> +        cpupool_create_pool(i, pool_sched_map[i]);
> +
> +#ifdef CONFIG_X86
> +    /* Cpu0 must be in cpupool0 for x86 */
> +    if ( pool_cpu_map[0] != 0 )
> +        panic("Cpu0 must be in Pool-0\n");
> +#endif
> +}
> +
> +unsigned int __init btcpupools_get_cpupool_id(unsigned int cpu)
> +{
> +    return pool_cpu_map[cpu];
> +}
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-file-style: "BSD"
> + * c-basic-offset: 4
> + * tab-width: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> diff --git a/xen/common/sched/cpupool.c b/xen/common/sched/cpupool.c
> index 89a891af7076..e5189c53a321 100644
> --- a/xen/common/sched/cpupool.c
> +++ b/xen/common/sched/cpupool.c
> @@ -1247,12 +1247,19 @@ static int __init cf_check cpupool_init(void)
>      cpupool_put(cpupool0);
>      register_cpu_notifier(&cpu_nfb);
>  
> +    btcpupools_dtb_parse();
> +
> +    btcpupools_allocate_pools();
> +
>      spin_lock(&cpupool_lock);
>  
>      cpumask_copy(&cpupool_free_cpus, &cpu_online_map);
>  
>      for_each_cpu ( cpu, &cpupool_free_cpus )
> -        cpupool_assign_cpu_locked(cpupool0, cpu);
> +    {
> +        unsigned int pool_id = btcpupools_get_cpupool_id(cpu);
> +        cpupool_assign_cpu_locked(cpupool_find_by_id(pool_id), cpu);
> +    }
>  
>      spin_unlock(&cpupool_lock);
>  
> diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
> index 4050e22544f9..5d83465d3915 100644
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -1176,6 +1176,25 @@ extern void cf_check dump_runq(unsigned char key);
>  
>  void arch_do_physinfo(struct xen_sysctl_physinfo *pi);
>  
> +#ifdef CONFIG_BOOT_TIME_CPUPOOLS
> +void btcpupools_allocate_pools(void);
> +unsigned int btcpupools_get_cpupool_id(unsigned int cpu);
> +
> +#ifdef CONFIG_HAS_DEVICE_TREE
> +void btcpupools_dtb_parse(void);
> +#else
> +static inline void btcpupools_dtb_parse(void) {}
> +#endif

same comment about !CONFIG_HAS_DEVICE_TREE


> +#else /* !CONFIG_BOOT_TIME_CPUPOOLS */
> +static inline void btcpupools_allocate_pools(void) {}
> +static inline void btcpupools_dtb_parse(void) {}
> +static inline unsigned int btcpupools_get_cpupool_id(unsigned int cpu)
> +{
> +    return 0;
> +}
> +#endif
> +
>  #endif /* __SCHED_H__ */
>  
>  /*

Re: [PATCH v3 5/6] arm/dom0less: assign dom0less guests to cpupools

[Stefano Stabellini]

On Fri, 18 Mar 2022, Luca Fancellu wrote:
> Introduce domain-cpupool property of a xen,domain device tree node,
> that specifies the cpupool device tree handle of a xen,cpupool node
> that identifies a cpupool created at boot time where the guest will
> be assigned on creation.
> 
> Add member to the xen_domctl_createdomain public interface so the
> XEN_DOMCTL_INTERFACE_VERSION version is bumped.
> 
> Add public function to retrieve a pool id from the device tree
> cpupool node.
> 
> Update documentation about the property.
> 
> Signed-off-by: Luca Fancellu <luca.fancellu@arm.com>
> ---
> Changes in v3:
> - Use explicitely sized integer for struct xen_domctl_createdomain
>   cpupool_id member. (Stefano)
> - Changed code due to previous commit code changes
> Changes in v2:
> - Moved cpupool_id from arch specific to common part (Juergen)
> - Implemented functions to retrieve the cpupool id from the
>   cpupool dtb node.
> ---
>  docs/misc/arm/device-tree/booting.txt |  5 +++++
>  xen/arch/arm/domain_build.c           | 14 +++++++++++++-
>  xen/common/boot_cpupools.c            | 24 ++++++++++++++++++++++++
>  xen/common/domain.c                   |  2 +-
>  xen/include/public/domctl.h           |  4 +++-
>  xen/include/xen/sched.h               |  9 +++++++++
>  6 files changed, 55 insertions(+), 3 deletions(-)
> 
> diff --git a/docs/misc/arm/device-tree/booting.txt b/docs/misc/arm/device-tree/booting.txt
> index a94125394e35..7b4a29a2c293 100644
> --- a/docs/misc/arm/device-tree/booting.txt
> +++ b/docs/misc/arm/device-tree/booting.txt
> @@ -188,6 +188,11 @@ with the following properties:
>      An empty property to request the memory of the domain to be
>      direct-map (guest physical address == physical address).
>  
> +- domain-cpupool
> +
> +    Optional. Handle to a xen,cpupool device tree node that identifies the
> +    cpupool where the guest will be started at boot.
> +
>  Under the "xen,domain" compatible node, one or more sub-nodes are present
>  for the DomU kernel and ramdisk.
>  
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index 8be01678de05..9c67a483d4a4 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -3172,7 +3172,8 @@ static int __init construct_domU(struct domain *d,
>  void __init create_domUs(void)
>  {
>      struct dt_device_node *node;
> -    const struct dt_device_node *chosen = dt_find_node_by_path("/chosen");
> +    const struct dt_device_node *cpupool_node,
> +                                *chosen = dt_find_node_by_path("/chosen");
>  
>      BUG_ON(chosen == NULL);
>      dt_for_each_child_node(chosen, node)
> @@ -3241,6 +3242,17 @@ void __init create_domUs(void)
>                                           vpl011_virq - 32 + 1);
>          }
>  
> +        /* Get the optional property domain-cpupool */
> +        cpupool_node = dt_parse_phandle(node, "domain-cpupool", 0);
> +        if ( cpupool_node )
> +        {
> +            int pool_id = btcpupools_get_domain_pool_id(cpupool_node);
> +            if ( pool_id < 0 )
> +                panic("Error getting cpupool id from domain-cpupool (%d)\n",
> +                      pool_id);
> +            d_cfg.cpupool_id = pool_id;
> +        }
> +
>          /*
>           * The variable max_init_domid is initialized with zero, so here it's
>           * very important to use the pre-increment operator to call
> diff --git a/xen/common/boot_cpupools.c b/xen/common/boot_cpupools.c
> index f6f2fa8f2701..feba93a243fc 100644
> --- a/xen/common/boot_cpupools.c
> +++ b/xen/common/boot_cpupools.c
> @@ -23,6 +23,8 @@ static unsigned int __initdata next_pool_id;
>  
>  #define BTCPUPOOLS_DT_NODE_NO_REG     (-1)
>  #define BTCPUPOOLS_DT_NODE_NO_LOG_CPU (-2)
> +#define BTCPUPOOLS_DT_WRONG_NODE      (-3)
> +#define BTCPUPOOLS_DT_CORRUPTED_NODE  (-4)
>  
>  static int __init get_logical_cpu_from_hw_id(unsigned int hwid)
>  {
> @@ -55,6 +57,28 @@ get_logical_cpu_from_cpu_node(const struct dt_device_node *cpu_node)
>      return cpu_num;
>  }
>  
> +int __init btcpupools_get_domain_pool_id(const struct dt_device_node *node)
> +{
> +    const struct dt_device_node *phandle_node;
> +    int cpu_num;
> +
> +    if ( !dt_device_is_compatible(node, "xen,cpupool") )
> +        return BTCPUPOOLS_DT_WRONG_NODE;
> +    /*
> +     * Get first cpu listed in the cpupool, from its reg it's possible to
> +     * retrieve the cpupool id.
> +     */
> +    phandle_node = dt_parse_phandle(node, "cpupool-cpus", 0);
> +    if ( !phandle_node )
> +        return BTCPUPOOLS_DT_CORRUPTED_NODE;
> +
> +    cpu_num = get_logical_cpu_from_cpu_node(phandle_node);
> +    if ( cpu_num < 0 )
> +        return cpu_num;
> +
> +    return pool_cpu_map[cpu_num];
> +}
> +
>  static int __init check_and_get_sched_id(const char* scheduler_name)
>  {
>      int sched_id = sched_get_id_by_name(scheduler_name);
> diff --git a/xen/common/domain.c b/xen/common/domain.c
> index 351029f8b239..0827400f4f49 100644
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -698,7 +698,7 @@ struct domain *domain_create(domid_t domid,
>          if ( !d->pbuf )
>              goto fail;
>  
> -        if ( (err = sched_init_domain(d, 0)) != 0 )
> +        if ( (err = sched_init_domain(d, config->cpupool_id)) != 0 )
>              goto fail;
>  
>          if ( (err = late_hwdom_init(d)) != 0 )
> diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
> index b85e6170b0aa..2f4cf56f438d 100644
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -38,7 +38,7 @@
>  #include "hvm/save.h"
>  #include "memory.h"
>  
> -#define XEN_DOMCTL_INTERFACE_VERSION 0x00000014
> +#define XEN_DOMCTL_INTERFACE_VERSION 0x00000015
>  
>  /*
>   * NB. xen_domctl.domain is an IN/OUT parameter for this operation.
> @@ -106,6 +106,8 @@ struct xen_domctl_createdomain {
>      /* Per-vCPU buffer size in bytes.  0 to disable. */
>      uint32_t vmtrace_size;
>  
> +    uint32_t cpupool_id;
> +
>      struct xen_arch_domainconfig arch;
>  };
>  
> diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
> index 5d83465d3915..4e749a604f25 100644
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -1182,6 +1182,7 @@ unsigned int btcpupools_get_cpupool_id(unsigned int cpu);
>  
>  #ifdef CONFIG_HAS_DEVICE_TREE
>  void btcpupools_dtb_parse(void);
> +int btcpupools_get_domain_pool_id(const struct dt_device_node *node);
>  #else
>  static inline void btcpupools_dtb_parse(void) {}
>  #endif
> @@ -1193,6 +1194,14 @@ static inline unsigned int btcpupools_get_cpupool_id(unsigned int cpu)
>  {
>      return 0;
>  }
> +#ifdef CONFIG_HAS_DEVICE_TREE
> +static inline int
> +btcpupools_get_domain_pool_id(const struct dt_device_node *node)
> +{
> +    return 0;
> +}
> +#endif

This is OK because in case !CONFIG_BOOT_TIME_CPUPOOLS, we have to handle
both the CONFIG_HAS_DEVICE_TREE and the !CONFIG_HAS_DEVICE_TREE.

It is the other case (CONFIG_BOOT_TIME_CPUPOOLS &&
!CONFIG_HAS_DEVICE_TREE) that is not possible.

This patch looks good to me.

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

Re: [PATCH v3 4/6] xen/cpupool: Create different cpupools at boot time

[Bertrand Marquis]

Hi Julien,

> On 21 Mar 2022, at 18:44, Julien Grall <julien@xen.org> wrote:
> 
> Hi Bertrand,
> 
> On 21/03/2022 17:19, Bertrand Marquis wrote:
>>> On 21 Mar 2022, at 17:36, Julien Grall <julien@xen.org> wrote:
>>>> So I don’t know why on x86 we must have cpu0 in cpupool0, maybe x86 maintainer have more knowledge about that and
>>>> I can put a comment here.
>>> 
>>> On Arm, we are not yet supporting all the CPU features that x86 supports (e.g. CPU hotplug, suspend/resume...). So I a am bit concerned that the restriction is just not there yet (or possibly hidden).
>>> 
>>> Therefore, before lifting the restriction on Arm (and other arch), I would like us to understand why it is necessary on x86.
>>> 
>>> We may not have the answer quickly, so is it going to be a problem to keep the restriction on Arm?
>> I am ok to keep the limitation to have dom0 always running on cpu0.
>> Only limitation I can see is that on a big little system, dom0 needs to stay on the type of core of the first booted core.
> 
> Where does this limitation come from?

If dom0 must run on core0 and core0 is Little then you cannot build a system where dom0 is running on big cores.
If the limitation is not there, you can build such a configuration without any dependency to the boot core type.

Cheers
Bertrand

> 
> Cheers,
> 
> -- 
> Julien Grall

Re: [PATCH v3 4/6] xen/cpupool: Create different cpupools at boot time

[Bertrand Marquis]

Hi Julien,

> On 22 Mar 2022, at 09:35, Bertrand Marquis <bertrand.marquis@arm.com> wrote:
> 
> Hi Julien,
> 
>> On 21 Mar 2022, at 18:44, Julien Grall <julien@xen.org> wrote:
>> 
>> Hi Bertrand,
>> 
>> On 21/03/2022 17:19, Bertrand Marquis wrote:
>>>> On 21 Mar 2022, at 17:36, Julien Grall <julien@xen.org> wrote:
>>>>> So I don’t know why on x86 we must have cpu0 in cpupool0, maybe x86 maintainer have more knowledge about that and
>>>>> I can put a comment here.
>>>> 
>>>> On Arm, we are not yet supporting all the CPU features that x86 supports (e.g. CPU hotplug, suspend/resume...). So I a am bit concerned that the restriction is just not there yet (or possibly hidden).
>>>> 
>>>> Therefore, before lifting the restriction on Arm (and other arch), I would like us to understand why it is necessary on x86.
>>>> 
>>>> We may not have the answer quickly, so is it going to be a problem to keep the restriction on Arm?
>>> I am ok to keep the limitation to have dom0 always running on cpu0.
>>> Only limitation I can see is that on a big little system, dom0 needs to stay on the type of core of the first booted core.
>> 
>> Where does this limitation come from?
> 
> If dom0 must run on core0 and core0 is Little then you cannot build a system where dom0 is running on big cores.
> If the limitation is not there, you can build such a configuration without any dependency to the boot core type.

This might not be completely clear so let me rephrase:
In the current system:
- dom0 must run on cpupool-0
- cpupool-0 must contain the boot core
- consequence: dom0 must run on the boot core

If boot core is little, you cannot build as system where dom0 runs only on the big cores.
Removing the second limitation (which is not required on arm) is making it possible.

Regards
Bertrand

Re: [PATCH v3 4/6] xen/cpupool: Create different cpupools at boot time

[Luca Fancellu]

>> +- cpupool-sched (optional)
>> +
>> +    Must be a string having the name of a Xen scheduler, it has no effect when
>> +    used in conjunction of a cpupool-id equal to zero, in that case the
>> +    default Xen scheduler is selected (sched=<...> boot argument).
>> +    Check the sched=<...> boot argument for allowed values.
> 
> I am happy with this version of the device tree bindings, thanks for
> your efforts to update them. Only one comment left: please update the
> description not to include "cpupool-id" given that there is no
> cpupool-id property anymore :-)
> 

Hi Stefano,

Thank you for your review,

Yes I missed that! I will fix in the next serie.

>> 
>> +/*
>> + * pool_cpu_map:   Index is logical cpu number, content is cpupool id, (-1) for
>> + *                 unassigned.
>> + * pool_sched_map: Index is cpupool id, content is scheduler id, (-1) for
>> + *                 unassigned.
>> + */
>> +static int __initdata pool_cpu_map[NR_CPUS]   = { [0 ... NR_CPUS-1] = -1 };
>> +static int __initdata pool_sched_map[NR_CPUS] = { [0 ... NR_CPUS-1] = -1 };
>> +static unsigned int __initdata next_pool_id;
>> +
>> +#ifdef CONFIG_HAS_DEVICE_TREE
> 
> BOOT_TIME_CPUPOOLS depends on HAS_DEVICE_TREE, so it is not possible to
> have BOOT_TIME_CPUPOOLS but not HAS_DEVICE_TREE ?

Yes you are right, the ifdef is not needed at this stage since only arch with device tree are
using it, if x86 would like to implement a command line version then the code will be ifdef-ined
later.

> 
> 
>> +#define BTCPUPOOLS_DT_NODE_NO_REG     (-1)
>> +#define BTCPUPOOLS_DT_NODE_NO_LOG_CPU (-2)
>> +
>> +static int __init get_logical_cpu_from_hw_id(unsigned int hwid)
>> +{
>> +    unsigned int i;
>> +
>> +    for ( i = 0; i < nr_cpu_ids; i++ )
>> +        if ( cpu_physical_id(i) == hwid )
>> +            return i;
>> +
>> +    return -1;
>> +}
> 
> I wonder if there is a better way to implement this function but I am
> not sure. Also, it might be better to avoid premature optimizations.
> 
> That said, we could check first the simple case where hwid==i. Looking
> at various existing device tree, it seems to be the most common case.
> 
> This is not a requirement, just a hand-wavy suggestion. I think the
> patch is also OK as is.
> 

Not sure to understand here, at least on FVP (the first DT I have around), hwid != i,
Or maybe I didn’t understand what you mean

> 
>> +void __init btcpupools_allocate_pools(void)
>> +{
>> +    unsigned int i;
>> +    bool add_extra_cpupool = false;
>> +
>> +    /*
>> +     * If there are no cpupools, the value of next_pool_id is zero, so the code
>> +     * below will assign every cpu to cpupool0 as the default behavior.
>> +     * When there are cpupools, the code below is assigning all the not
>> +     * assigned cpu to a new pool (next_pool_id value is the last id + 1).
>> +     * In the same loop we check if there is any assigned cpu that is not
>> +     * online.
>> +     */
>> +    for ( i = 0; i < nr_cpu_ids; i++ )
>> +        if ( cpumask_test_cpu(i, &cpu_online_map) )
> 
> Let me take this opportunity to explain the unfortunately unwritten
> coding style the way I understand it. I know this is tribal knowledge at
> the moment and I apologize for that.
> 
> If it is a single line statement, we skip the { }, we keep them in all
> other cases.
> 
> So:
> 
>  /* correct */
>  if ( xxx ) {
>      something;
>      something else;
>  }
> 
>  /* correct */
>  if ( xxx ) {
>      for ( yyy ) {
>      }
>  }
> 
>  /* correct */
>  if ( xxx )
>      something single line or 2 lines like a printk that go beyond 80
>      chars, never in case of nested ifs
> 
>  /* not correct */
>  if ( xxx )
>      something
>      multi
>      line;
> 
>  /* not correct */
>  if ( xxx )
>      if ( yyy )
>          something;
> 
> So basically we would keep the { } here but we would skip them ...

Ok this clarifies a lot, thank you, I will check the code and I will fix it where it’s not
compliant.

> 
>> +#ifdef CONFIG_HAS_DEVICE_TREE
>> +void btcpupools_dtb_parse(void);
>> +#else
>> +static inline void btcpupools_dtb_parse(void) {}
>> +#endif
> 
> same comment about !CONFIG_HAS_DEVICE_TREE

Yes I will fix it in the next serie.

Cheers,
Luca

Re: [PATCH v3 4/6] xen/cpupool: Create different cpupools at boot time

[Julien Grall]

Hi,

On 22/03/2022 08:47, Bertrand Marquis wrote:
> Hi Julien,
> 
>> On 22 Mar 2022, at 09:35, Bertrand Marquis <bertrand.marquis@arm.com> wrote:
>>
>> Hi Julien,
>>
>>> On 21 Mar 2022, at 18:44, Julien Grall <julien@xen.org> wrote:
>>>
>>> Hi Bertrand,
>>>
>>> On 21/03/2022 17:19, Bertrand Marquis wrote:
>>>>> On 21 Mar 2022, at 17:36, Julien Grall <julien@xen.org> wrote:
>>>>>> So I don’t know why on x86 we must have cpu0 in cpupool0, maybe x86 maintainer have more knowledge about that and
>>>>>> I can put a comment here.
>>>>>
>>>>> On Arm, we are not yet supporting all the CPU features that x86 supports (e.g. CPU hotplug, suspend/resume...). So I a am bit concerned that the restriction is just not there yet (or possibly hidden).
>>>>>
>>>>> Therefore, before lifting the restriction on Arm (and other arch), I would like us to understand why it is necessary on x86.
>>>>>
>>>>> We may not have the answer quickly, so is it going to be a problem to keep the restriction on Arm?
>>>> I am ok to keep the limitation to have dom0 always running on cpu0.
>>>> Only limitation I can see is that on a big little system, dom0 needs to stay on the type of core of the first booted core.
>>>
>>> Where does this limitation come from?
>>
>> If dom0 must run on core0 and core0 is Little then you cannot build a system where dom0 is running on big cores.
>> If the limitation is not there, you can build such a configuration without any dependency to the boot core type.
> 
> This might not be completely clear so let me rephrase:
> In the current system:
> - dom0 must run on cpupool-0

I don't think we need this restriction. In fact, with this series it 
will become more a problem because the cpupool ID will based on how we 
parse the Device-Tree.

So for dom0, we need to specify explicitely the cpupool to be used.

> - cpupool-0 must contain the boot core
> - consequence: dom0 must run on the boot core
> 
> If boot core is little, you cannot build as system where dom0 runs only on the big cores.
> Removing the second limitation (which is not required on arm) is making it possible.

IMHO removing the second restriction is a lot more risky than removing 
the first one.

Cheers,

-- 
Julien Grall

Re: [PATCH v3 4/6] xen/cpupool: Create different cpupools at boot time

[Bertrand Marquis]

Hi Julien,

> On 22 Mar 2022, at 10:16, Julien Grall <julien@xen.org> wrote:
> 
> Hi,
> 
> On 22/03/2022 08:47, Bertrand Marquis wrote:
>> Hi Julien,
>>> On 22 Mar 2022, at 09:35, Bertrand Marquis <bertrand.marquis@arm.com> wrote:
>>> 
>>> Hi Julien,
>>> 
>>>> On 21 Mar 2022, at 18:44, Julien Grall <julien@xen.org> wrote:
>>>> 
>>>> Hi Bertrand,
>>>> 
>>>> On 21/03/2022 17:19, Bertrand Marquis wrote:
>>>>>> On 21 Mar 2022, at 17:36, Julien Grall <julien@xen.org> wrote:
>>>>>>> So I don’t know why on x86 we must have cpu0 in cpupool0, maybe x86 maintainer have more knowledge about that and
>>>>>>> I can put a comment here.
>>>>>> 
>>>>>> On Arm, we are not yet supporting all the CPU features that x86 supports (e.g. CPU hotplug, suspend/resume...). So I a am bit concerned that the restriction is just not there yet (or possibly hidden).
>>>>>> 
>>>>>> Therefore, before lifting the restriction on Arm (and other arch), I would like us to understand why it is necessary on x86.
>>>>>> 
>>>>>> We may not have the answer quickly, so is it going to be a problem to keep the restriction on Arm?
>>>>> I am ok to keep the limitation to have dom0 always running on cpu0.
>>>>> Only limitation I can see is that on a big little system, dom0 needs to stay on the type of core of the first booted core.
>>>> 
>>>> Where does this limitation come from?
>>> 
>>> If dom0 must run on core0 and core0 is Little then you cannot build a system where dom0 is running on big cores.
>>> If the limitation is not there, you can build such a configuration without any dependency to the boot core type.
>> This might not be completely clear so let me rephrase:
>> In the current system:
>> - dom0 must run on cpupool-0
> 
> I don't think we need this restriction. In fact, with this series it will become more a problem because the cpupool ID will based on how we parse the Device-Tree.
> 
> So for dom0, we need to specify explicitely the cpupool to be used.
> 
>> - cpupool-0 must contain the boot core
>> - consequence: dom0 must run on the boot core
>> If boot core is little, you cannot build as system where dom0 runs only on the big cores.
>> Removing the second limitation (which is not required on arm) is making it possible.
> 
> IMHO removing the second restriction is a lot more risky than removing the first one.

So keeping boot core in cpupool-0 but allow Dom-0 to be in any pool.
Interesting, we will check that.

Cheers
Bertrand

> 
> Cheers,
> 
> -- 
> Julien Grall

Re: [PATCH v3 4/6] xen/cpupool: Create different cpupools at boot time

[Luca Fancellu]

>>> 
>>> Can you document why this is necessary on x86 but not on other architectures?
>> Hi Julien,
>> I received the warning by Juergen here: https://patchwork.kernel.org/comment/24740762/ that at least on x86 there could be
>> some problems if cpu0 is not in cpupool0, I tested it on arm and it was working fine and I didn’t find any restriction.
> 
> What exactly did you test on Arm?
> 

I have tested start/stop of some guest, moving cpus between cpupools, create/destroy cpupools, shutdown of Dom0


[ from your last mail ]
>>> 
>>> If dom0 must run on core0 and core0 is Little then you cannot build a system where dom0 is running on big cores.
>>> If the limitation is not there, you can build such a configuration without any dependency to the boot core type.
>> This might not be completely clear so let me rephrase:
>> In the current system:
>> - dom0 must run on cpupool-0
> 
> I don't think we need this restriction. In fact, with this series it will become more a problem because the cpupool ID will based on how we parse the Device-Tree.
> 
> So for dom0, we need to specify explicitely the cpupool to be used.
> 
>> - cpupool-0 must contain the boot core
>> - consequence: dom0 must run on the boot core
>> If boot core is little, you cannot build as system where dom0 runs only on the big cores.
>> Removing the second limitation (which is not required on arm) is making it possible.
> 
> IMHO removing the second restriction is a lot more risky than removing the first one.

I see your point, my concern about moving Dom0 on another cpupool, different from cpupool0, is that we give the
opportunity to destroy the cpupool0 (we can’t let that happen), or remove every cpu from cpupool0.

Cheers,
Luca

Re: [PATCH v3 4/6] xen/cpupool: Create different cpupools at boot time

[Julien Grall]

Hi,

On 22/03/2022 09:52, Luca Fancellu wrote:
>>>>
>>>> Can you document why this is necessary on x86 but not on other architectures?
>>> Hi Julien,
>>> I received the warning by Juergen here: https://patchwork.kernel.org/comment/24740762/ that at least on x86 there could be
>>> some problems if cpu0 is not in cpupool0, I tested it on arm and it was working fine and I didn’t find any restriction.
>>
>> What exactly did you test on Arm?
>>
> 
> I have tested start/stop of some guest, moving cpus between cpupools, create/destroy cpupools, shutdown of Dom0
> 
> 
> [ from your last mail ]
>>>>
>>>> If dom0 must run on core0 and core0 is Little then you cannot build a system where dom0 is running on big cores.
>>>> If the limitation is not there, you can build such a configuration without any dependency to the boot core type.
>>> This might not be completely clear so let me rephrase:
>>> In the current system:
>>> - dom0 must run on cpupool-0
>>
>> I don't think we need this restriction. In fact, with this series it will become more a problem because the cpupool ID will based on how we parse the Device-Tree.
>>
>> So for dom0, we need to specify explicitely the cpupool to be used.
>>
>>> - cpupool-0 must contain the boot core
>>> - consequence: dom0 must run on the boot core
>>> If boot core is little, you cannot build as system where dom0 runs only on the big cores.
>>> Removing the second limitation (which is not required on arm) is making it possible.
>>
>> IMHO removing the second restriction is a lot more risky than removing the first one.
> 
> I see your point, my concern about moving Dom0 on another cpupool, different from cpupool0, is that we give the
> opportunity to destroy the cpupool0 (we can’t let that happen), or remove every cpu from cpupool0.

 From my understanding a cpupool can only be destroyed when there are no 
more CPUs in the pool. Given that cpu0 has to be in pool0 then this 
should prevent the pool to be destroyed.

Now, it is quite possible that we don't have a check to prevent CPU0 to 
be removed from cpupool0. If so, then I would argue we should add the 
check otherwise it is pointless to prevent cpu0 to be initially added in 
another pool than pool0 but can be moved afterwards.

Cheers,

-- 
Julien Grall

Re: [PATCH v3 5/6] arm/dom0less: assign dom0less guests to cpupools

[Luca Fancellu]

+ maintainer golang, libs, ocaml, python bindings

> On 18 Mar 2022, at 16:18, Julien Grall <julien@xen.org> wrote:
> 
> Hi,
> 
> On 18/03/2022 15:25, Luca Fancellu wrote:
>> Introduce domain-cpupool property of a xen,domain device tree node,
>> that specifies the cpupool device tree handle of a xen,cpupool node
>> that identifies a cpupool created at boot time where the guest will
>> be assigned on creation.
>> Add member to the xen_domctl_createdomain public interface so the
>> XEN_DOMCTL_INTERFACE_VERSION version is bumped.
>> Add public function to retrieve a pool id from the device tree
>> cpupool node.
>> Update documentation about the property.
>> Signed-off-by: Luca Fancellu <luca.fancellu@arm.com>
>> ---
>> Changes in v3:
>> - Use explicitely sized integer for struct xen_domctl_createdomain
>>   cpupool_id member. (Stefano)
>> - Changed code due to previous commit code changes
>> Changes in v2:
>> - Moved cpupool_id from arch specific to common part (Juergen)
>> - Implemented functions to retrieve the cpupool id from the
>>   cpupool dtb node.
>> ---
>>  docs/misc/arm/device-tree/booting.txt |  5 +++++
>>  xen/arch/arm/domain_build.c           | 14 +++++++++++++-
>>  xen/common/boot_cpupools.c            | 24 ++++++++++++++++++++++++
>>  xen/common/domain.c                   |  2 +-
>>  xen/include/public/domctl.h           |  4 +++-
>>  xen/include/xen/sched.h               |  9 +++++++++
> 
> This patch doesn't seem to contain any change in tools. So...
> 
>>          if ( (err = late_hwdom_init(d)) != 0 )
>> diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
>> index b85e6170b0aa..2f4cf56f438d 100644
>> --- a/xen/include/public/domctl.h
>> +++ b/xen/include/public/domctl.h
>> @@ -38,7 +38,7 @@
>>  #include "hvm/save.h"
>>  #include "memory.h"
>>  -#define XEN_DOMCTL_INTERFACE_VERSION 0x00000014
>> +#define XEN_DOMCTL_INTERFACE_VERSION 0x00000015
>>    /*
>>   * NB. xen_domctl.domain is an IN/OUT parameter for this operation.
>> @@ -106,6 +106,8 @@ struct xen_domctl_createdomain {
>>      /* Per-vCPU buffer size in bytes.  0 to disable. */
>>      uint32_t vmtrace_size;
>>  +    uint32_t cpupool_id;
> 
> ... will the tools (e.g. golang bindings, libxl,..) always zero xen_domctl_createdomain?
> 
> I also think we may need to regenerate the golang bindings.

I’ve checked the occurrences of struct xen_domctl_createdomain in tools/ and I see it is
always initialised using designated initializers so (correct me if I’m wrong) any non specified
field should be zero.

I tried to check if I need and how to regenerate the golang bindings, I didn’t find documentation
to do that, I’ve added some maintainer to this reply that hopefully can help me to understand
If I’ve missed something in this patch modifying struct xen_domctl_createdomain.

Cheers,
Luca

> 
> Cheers,
> 
> -- 
> Julien Grall

Re: [PATCH v3 4/6] xen/cpupool: Create different cpupools at boot time

[Stefano Stabellini]

[-- Attachment #1: Type: text/plain, Size: 3013 bytes --]

On Tue, 22 Mar 2022, Luca Fancellu wrote:
> >> +- cpupool-sched (optional)
> >> +
> >> +    Must be a string having the name of a Xen scheduler, it has no effect when
> >> +    used in conjunction of a cpupool-id equal to zero, in that case the
> >> +    default Xen scheduler is selected (sched=<...> boot argument).
> >> +    Check the sched=<...> boot argument for allowed values.
> > 
> > I am happy with this version of the device tree bindings, thanks for
> > your efforts to update them. Only one comment left: please update the
> > description not to include "cpupool-id" given that there is no
> > cpupool-id property anymore :-)
> > 
> 
> Hi Stefano,
> 
> Thank you for your review,
> 
> Yes I missed that! I will fix in the next serie.
> 
> >> 
> >> +/*
> >> + * pool_cpu_map:   Index is logical cpu number, content is cpupool id, (-1) for
> >> + *                 unassigned.
> >> + * pool_sched_map: Index is cpupool id, content is scheduler id, (-1) for
> >> + *                 unassigned.
> >> + */
> >> +static int __initdata pool_cpu_map[NR_CPUS]   = { [0 ... NR_CPUS-1] = -1 };
> >> +static int __initdata pool_sched_map[NR_CPUS] = { [0 ... NR_CPUS-1] = -1 };
> >> +static unsigned int __initdata next_pool_id;
> >> +
> >> +#ifdef CONFIG_HAS_DEVICE_TREE
> > 
> > BOOT_TIME_CPUPOOLS depends on HAS_DEVICE_TREE, so it is not possible to
> > have BOOT_TIME_CPUPOOLS but not HAS_DEVICE_TREE ?
> 
> Yes you are right, the ifdef is not needed at this stage since only arch with device tree are
> using it, if x86 would like to implement a command line version then the code will be ifdef-ined
> later.
> 
> > 
> > 
> >> +#define BTCPUPOOLS_DT_NODE_NO_REG     (-1)
> >> +#define BTCPUPOOLS_DT_NODE_NO_LOG_CPU (-2)
> >> +
> >> +static int __init get_logical_cpu_from_hw_id(unsigned int hwid)
> >> +{
> >> +    unsigned int i;
> >> +
> >> +    for ( i = 0; i < nr_cpu_ids; i++ )
> >> +        if ( cpu_physical_id(i) == hwid )
> >> +            return i;
> >> +
> >> +    return -1;
> >> +}
> > 
> > I wonder if there is a better way to implement this function but I am
> > not sure. Also, it might be better to avoid premature optimizations.
> > 
> > That said, we could check first the simple case where hwid==i. Looking
> > at various existing device tree, it seems to be the most common case.
> > 
> > This is not a requirement, just a hand-wavy suggestion. I think the
> > patch is also OK as is.
> > 
> 
> Not sure to understand here, at least on FVP (the first DT I have around), hwid != i,
> Or maybe I didn’t understand what you mean

I am not surprised. In many boards hwid == i, but it is not a guarantee
at all.

To be honest mine was not really a concrete suggestion, more like the
beginning of a discussion on the subject. The goal would be to avoid
having to scan the __cpu_logical_map array every time without adding a
second data structure. I don't feel strongly about it but I thought I
would mention it anyway just in case you (or someone else) gets a better
idea on how to do this.

Re: [PATCH v3 4/6] xen/cpupool: Create different cpupools at boot time

[Luca Fancellu]

> On 22 Mar 2022, at 14:01, Julien Grall <julien@xen.org> wrote:
> 
> Hi,
> 
> On 22/03/2022 09:52, Luca Fancellu wrote:
>>>>> 
>>>>> Can you document why this is necessary on x86 but not on other architectures?
>>>> Hi Julien,
>>>> I received the warning by Juergen here: https://patchwork.kernel.org/comment/24740762/ that at least on x86 there could be
>>>> some problems if cpu0 is not in cpupool0, I tested it on arm and it was working fine and I didn’t find any restriction.
>>> 
>>> What exactly did you test on Arm?
>>> 
>> I have tested start/stop of some guest, moving cpus between cpupools, create/destroy cpupools, shutdown of Dom0
>> [ from your last mail ]
>>>>> 
>>>>> If dom0 must run on core0 and core0 is Little then you cannot build a system where dom0 is running on big cores.
>>>>> If the limitation is not there, you can build such a configuration without any dependency to the boot core type.
>>>> This might not be completely clear so let me rephrase:
>>>> In the current system:
>>>> - dom0 must run on cpupool-0
>>> 
>>> I don't think we need this restriction. In fact, with this series it will become more a problem because the cpupool ID will based on how we parse the Device-Tree.
>>> 
>>> So for dom0, we need to specify explicitely the cpupool to be used.
>>> 
>>>> - cpupool-0 must contain the boot core
>>>> - consequence: dom0 must run on the boot core
>>>> If boot core is little, you cannot build as system where dom0 runs only on the big cores.
>>>> Removing the second limitation (which is not required on arm) is making it possible.
>>> 
>>> IMHO removing the second restriction is a lot more risky than removing the first one.
>> I see your point, my concern about moving Dom0 on another cpupool, different from cpupool0, is that we give the
>> opportunity to destroy the cpupool0 (we can’t let that happen), or remove every cpu from cpupool0.
> 
> From my understanding a cpupool can only be destroyed when there are no more CPUs in the pool. Given that cpu0 has to be in pool0 then this should prevent the pool to be destroyed.
> 
> Now, it is quite possible that we don't have a check to prevent CPU0 to be removed from cpupool0. If so, then I would argue we should add the check otherwise it is pointless to prevent cpu0 to be initially added in another pool than pool0 but can be moved afterwards.
> 

Hi Julien,

I’ve done a test on fvp, first finding is that cpu0 can be removed from Pool-0, there is no check.
Afterwards I’ve created another pool and I’ve assigned a cpu to it, I’ve called xl cpupool-destroy and the tool removes every cpu from the pool before destroying.

Do you think the check that prevents CPU0 to be removed from Pool-0 should be done in the tools or in Xen?

With this change it could be possible to protect cpu0:

diff --git a/xen/common/sched/cpupool.c b/xen/common/sched/cpupool.c
index a6da4970506a..703005839dd6 100644
--- a/xen/common/sched/cpupool.c
+++ b/xen/common/sched/cpupool.c
@@ -585,6 +585,12 @@ static int cpupool_unassign_cpu(struct cpupool *c, unsigned int cpu)
     if ( !cpu_online(cpu) )
         return -EINVAL;
 
+    if ( !c->cpupool_id && !cpu )
+    {
+        debugtrace_printk("Cpu0 must be in pool with id 0.\n");
+        return -EINVAL;
+    }
+
     master_cpu = sched_get_resource_cpu(cpu);
     ret = cpupool_unassign_cpu_start(c, master_cpu);
     if ( ret )

Cheers,
Luca


> Cheers,
> 
> -- 
> Julien Grall

Re: [PATCH v3 4/6] xen/cpupool: Create different cpupools at boot time

[Julien Grall]

Hi,

On 23/03/2022 13:58, Luca Fancellu wrote:
>> On 22 Mar 2022, at 14:01, Julien Grall <julien@xen.org> wrote:
>>
>> Hi,
>>
>> On 22/03/2022 09:52, Luca Fancellu wrote:
>>>>>>
>>>>>> Can you document why this is necessary on x86 but not on other architectures?
>>>>> Hi Julien,
>>>>> I received the warning by Juergen here: https://patchwork.kernel.org/comment/24740762/ that at least on x86 there could be
>>>>> some problems if cpu0 is not in cpupool0, I tested it on arm and it was working fine and I didn’t find any restriction.
>>>>
>>>> What exactly did you test on Arm?
>>>>
>>> I have tested start/stop of some guest, moving cpus between cpupools, create/destroy cpupools, shutdown of Dom0
>>> [ from your last mail ]
>>>>>>
>>>>>> If dom0 must run on core0 and core0 is Little then you cannot build a system where dom0 is running on big cores.
>>>>>> If the limitation is not there, you can build such a configuration without any dependency to the boot core type.
>>>>> This might not be completely clear so let me rephrase:
>>>>> In the current system:
>>>>> - dom0 must run on cpupool-0
>>>>
>>>> I don't think we need this restriction. In fact, with this series it will become more a problem because the cpupool ID will based on how we parse the Device-Tree.
>>>>
>>>> So for dom0, we need to specify explicitely the cpupool to be used.
>>>>
>>>>> - cpupool-0 must contain the boot core
>>>>> - consequence: dom0 must run on the boot core
>>>>> If boot core is little, you cannot build as system where dom0 runs only on the big cores.
>>>>> Removing the second limitation (which is not required on arm) is making it possible.
>>>>
>>>> IMHO removing the second restriction is a lot more risky than removing the first one.
>>> I see your point, my concern about moving Dom0 on another cpupool, different from cpupool0, is that we give the
>>> opportunity to destroy the cpupool0 (we can’t let that happen), or remove every cpu from cpupool0.
>>
>>  From my understanding a cpupool can only be destroyed when there are no more CPUs in the pool. Given that cpu0 has to be in pool0 then this should prevent the pool to be destroyed.
>>
>> Now, it is quite possible that we don't have a check to prevent CPU0 to be removed from cpupool0. If so, then I would argue we should add the check otherwise it is pointless to prevent cpu0 to be initially added in another pool than pool0 but can be moved afterwards.
>>
> 
> Hi Julien,
> 
> I’ve done a test on fvp, first finding is that cpu0 can be removed from Pool-0, there is no check.
> Afterwards I’ve created another pool and I’ve assigned a cpu to it, I’ve called xl cpupool-destroy and the tool removes every cpu from the pool before destroying.
> 
> Do you think the check that prevents CPU0 to be removed from Pool-0 should be done in the tools or in Xen?

I think we want a check at least in Xen (so we don't trust the tools to 
do the right thing).

We could also add one in the tools to provide better diagnostics to the 
user (this tends to be a request from Andrew).

Cheers,

-- 
Julien Grall